I’m wondering , is there some way possible to only allow 1 participant to enter into a raffle type scenario?
Would self sovereign identity combined with WebAuthn somehow be able to fix this issue? I might be overly simplifying this but worth a shot.
Would it be sufficient to use a variable in the canister that is “Principal of the 1 participant”, and update methods that change the Principal value of that oneParticipant variable?
Could you explain that a little further please?
I think he’s asking if we will know somehow that someone with the two-different-principles is of the same-person. It would be sufficient if the canister was able to tell that it’s the same person just with a different principle.
We use concepts of identity delegation, or having hot keys (webauthn identity) authorized to act on behalf of a cold key identity. You can link the various identities using whatever application logic or data structure suits your needs.
The short answer is that Dfinity’s existing tools solve the challenge of using one identity per browser, but do not determine how your application stores that identity or links together your various devices or browsers. There are plenty of good approaches to take, but we don’t have a full-service Okta or Auth0 style application at this point.
Thanks for your reply.
I look forward to seeing how this might work in practice…I suppose the goal I would be attempting to achieve would be to prevent ticket bots etc that could overload a service and enter multiple times for a prize
With the above suggestion , I could have multiple single identity browser windows open and enter multiple times or do I misunderstand?
1 Like
In my experience, WebAuthn generates a new identity for incognito browsers or after clearing application data, so it’s not going to do any heavy lifting for bot protection, unfortunately
Got it…guess I gotta try come up with a different solution to this problem
Thanks for the info
Maybe another reach but could your fingerprint be uniquely stored on the IC and then assigned to a profile/identity?
For instance , if I wanted to create multiple accounts I could not re use the same fingerprint ever again? Leaving me with a maximum 10 prints for 10 accounts?
I believe this is referred to as template hashing on ethereum
I found this article which suggests this may be possible on ethereum and IFPS …there is some sample code down the bottom of the article page 13
I think it is suggesting converting a fingerprint template to hash and then storing this in a smart contract on IFPS…could this same logic apply on ICP?
1 Like
Hey thanks for the communication, i have a question though on this, if webauthn generates a new identity for a new browser or if the application data is cleared, then how will lets say a new user who doesnt know anything bout the blockchain and: keys, how will they gain access to their accounts on the canisters if their data gets cleared on their browser or if they get a new browser or a new computer?
also is webauthn the same thing as the self-sovereign-identity that Dom is talking bout?
1 Like
Without wanting to overstep my bounds, I would say that self-sovereign identity is a goal we would like to see realized on the IC, rather than a promise for Genesis.
We will have a more technical talk on what we have for identity, but that work isn’t going to automatically handle knowing who a person actually is IRL or what permissions they have. That is application logic that will still need to be built for your app, or provided by some identity service that doesn’t exist yet. We think that web authentication has a place in that whole recipe, but we and the apps we’re partnering with are still actively figuring out how it all comes together
2 Likes
“Self Sovereign Identity” is a loosely defined term. Self-sovereign identity - Wikipedia
I’ve been studying it for a few years, and I’m not sure SSI alone really helps with @Emmo’s use case. SSI should afford for anyone to be empowered to present as the identity of their choice, perhaps amongst a bag of several identities that that same person uses in different contexts. groups of people, even, should perhaps be able to cooperate to present as a single identity… e.g. a software development team who cooperatively control a canister. For Tracking Prevention, the same device should also have a different Principal per canister. The Principal is not a unique identifier for the end-user.
If an end-user chooses to present themselves as many identities (or as part of a group identity), not just one, that’s a feature (to them), not a bug (maybe to you, but not to them). For example, I expect every human to have many Principals, at the very least because they will (probably) have a unique Principal for each device they use to access a given canister.
Now, this flexibility at the system layer may be frustrating to you ‘one ticket per person’ use case. On the other hand, there is nothing preventing someone from using this flexibility to build something less flexibile on top of it.
You should look into “Proof of Personhood”. It’s a hard problem. Definitely no ‘one size fits all’ approach that is ‘self-sovereign’ to the end-user and also ‘provably correct’ for someone with your use case, because by-my-understanding those two design goals are inherently at odds with one another.
5 Likes
I had been looking at the possibility of using the Webauthn api…in here , the “authenticator” device I.e biometric signature from a phone or yubikey etc , has an authenticator ID. If this could be assigned to a user profile during the the webauthn process when entering a raffle , it could possibly stop multiple entries unless a user had multiple “authenticator” devices which is possible but costly and maybe be a viable deterrent…at least on a massive scale
I think this would look something look this. :
- Sign in/register website with webauthn process
- Enter raffle , registration of profile id + unique webauthn authenticator device ID
- only one device registration per entry
So I could have multiplie accounts on the site but in order to enter multiple times to a raffle , I would need a new authenticator device for each entry
1 Like
Ignoring web browsers and WebAuthn, lets say your canister is handling a request to enter the raffle. Let’s say that method requires presenting a unique ‘authenticatorId’. What algorithm would you run to make sure that that the proposed authenticatorId value isn’t just something I came up with off the top of my head (or a random string of the correct length/charset)?
This is the golden question , how can you verify or limit an identity/entry to just one time!
I’m really trying hard to figure this problem out but I’m not a developer so just trying to piece possible solutions together…this is a unique problem to solve but with massive potential in my opinion.
Gotta keep doing some research but if anyone would like to help or have any suggestions , by all means get in touch
We might need some proof of humanity
Or we could pair the authenticator id with an external identity provider. In France we have a “France connect” auth provider which is a proof that we are french.
I’ve also been approved on https://www.brightid.org
The onboarding is made via a discord call with the webcam on to verify that the picture you submited is really a picture of you.
If you are verified by enough People, then your account is verified.
Yes this is a possible route also.
I think I would prefer a solution on the IC if possible either through API or logic based solutions.
But will for sure look into all avenues.
1 Like
Looking to revise this old idea…Any devs out there interested now that IC has been launched for almost a year?