-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
API design should emphasize that sites should request minimal properties, not full identity documents #43
Comments
Bit old school, but |
Perhaps consider not blurring "identity" and "identifier", so consider |
2023-11-06 call:
More preferred:
Plan to close in two weeks. |
Sounded like maybe |
I get the "claims" thing, but it smells bit a bit "lawyery" (no offense to any lawyers).
The properties are attached to "something" thought (i.e., identity documents). mDoc at least deals with "documents", and what you get back is a document representation, right? What do other standards give back.
The problem of over requesting is at the protocol layer, not at the request API. We can call it whatever, but the problem is that you can still do:
So I just don't think we can restrict it anything at this level. A more suitable mental model might be that, as developer, you are asking for basically a document template to be filled out - but hopefully with the understanding that there is not expectation that you will get back what you asked for. So maybe, |
Naming alone certainly won't protect against abusive overasking, but API design is something that is communicated to developers, and so it should be one place we communicate expectations. Is the model that the developer gets back a document? Something like "age over 18" or "has a degree from an educational institution" aren't really document-like, but claim-like. While I understand "claims" to be the common term of art, I don't know what will actually be most comprehensible by developers that consume the API. |
"age over 18" or "has a degree from an educational institution" are documents when they are issued by an issuing authority attesting it. They are maybe claims when they are self asserted and that is not what we are covering with this API. What this API returns is not a claim it is more the document proving the claim. |
I own some document-like objects that show my birth date and that I have a PhD in information science from UC Berkeley. I haven't yet come across a document that says "this person is over 18" or a document that says "this person has an academic degree from an American college". |
As a non-mDoc/real-life example, please see also: https://www.vic.gov.au/proof-of-age-card "The Victorian Proof of Age card can be used to show proof of age for people over 18 years. This card is recognised throughout Australia." It can be used by people who don't have a driver's license to prove they are over 18 (e.g., to buy booze, enter night clubs, etc). |
That Australian Proof of Age card example includes a sample card ... that shows the holder's date of birth, full name and street address. I just meant that we aren't accustomed to documents that only show assertions of particular claims, we are accustomed to documents that present a broad selection of identifying details about a person, from which one can draw claims, like a proof of their age. But I believe the goal for this work should be to emphasize the communication of claims, not of full identity documents. |
A credential? |
FWIW I absolutely think we can restrict this and just refuse to honor any request that refuses to list the properties it wants (or otherwise treat it as risky, as we may treat a custom-scheme invocation). |
Notes from 2023-11-15 calls: https://github.com/WICG/identity-credential/wiki/2023-11-15-Meeting-Notes#api-design-should-emphasize-that-sites-should-request-minimal-properties-not-full-identity-documents Highlighting an something from the discussion: support for selective disclosure could be mandated to be included in the registry for "protocol". |
From 2024-07-29 call, comment added to #58. Closing issue. |
It might sound a little like bike-shedding, but I am concerned in seeing API methods called
requestIdentity
, as it seems to suggest that what you will get back is the user's complete identity.If successfully, responsibly deployed, the vast majority of uses of this API should return responses with particular properties or claims or proofs from a credential, but not what the developer might think of as the user's identity.
How can we design an API that makes it clear that sites should ask for only what they need, and not over-ask?
(this is for dc2-proposal but I don't have label permission)
The text was updated successfully, but these errors were encountered: