Align Model terminology with multiple digital credential ecosystems. #83
Conversation
msporny
requested review from
marcoscaceres,
samuelgoto,
RByers and
timcappalli
as code owners
index.html
Outdated
| credentials=] [[VC-DATA-MODEL-2.0]]. | ||
| </dd> | ||
| <dt> | ||
| <dfn>Credential provider</dfn> |
There was a problem hiding this comment.
Alternates include:
- Credential store (which is what CREDMAN calls this concept)
- Credential repository (which is what VCDM calls this concept)
- Credential manager (would this interfere w/ CREDMAN's definition?)
There was a problem hiding this comment.
Yeah, we wanted something that covers basically these things being "remote" too (i.e., you can pull them from the browser, or multiple wallet apps, etc.)... so it's kinda like a manager?
There was a problem hiding this comment.
Yes, agreed that "manager" is probably the better term. CREDMAN uses it in a slightly different way (AND doesn't define it)...
https://www.w3.org/TR/credential-management-1/#introduction
"Credential manager" in the CREDMAN usage of the term ties the "credential manager" to the user agent, often referring to it as "the user agent's credential manager". For this API, the two aren't tightly coupled, where the "credential manager" (digital wallet) is typically a completely separate application from the "user agent" (web browser).
There was a problem hiding this comment.
we do not use credential provider term in OpenID4VC ecosystem. I think it would reflect commonly used terminology better if a defined term is Wallet and the description can mention the relationship with login managers (though not sure why we need to talk about login managers at all - guess because credman api is being reused..)
There was a problem hiding this comment.
"Wallet" feels very concrete and product...y..., but it's definitely the right concept.
However, I'm hesitant to use "wallet" because it's a loaded from a UI perspective.
I guess what we'd like to convey here is more around the "role" that this bit of middleware plays... like, it may be a piece of software that acts as a wallet, but also allows you to select other wallets... plus coordinates the flow of data between itself and other wallets (as well as presenting UI).
There was a problem hiding this comment.
I'll give "credential manager" a shot if we think that "credential provider" isn't going to work out.
"manager" is highly overloaded in Web Platform, and "credential manager", specifically means a lot of other things. "credential provider" isn't great, but I think is less ambiguous than "credential manager".
But also, I think we are missing one big architectural element here (speaking only for the choices that Android has made so far), which is that the [=user agent=] has a "registry" of all of the credentials from [=holders=] which it uses to build a cross-wallet credential selector. That is, I think we need to find a way to introduce this level of aggregation across wallets, because that's what the JS API "talks to", rather than directly to the actual [=holders=] up front.
Am I making sense?
There was a problem hiding this comment.
Yeah, that makes sense @samuelgoto. I think you articulated it well.
There was a problem hiding this comment.
"credential provider" isn't great, but I think is less ambiguous than "credential manager".
lol -- alright, back to "credential provider" it is! I'll make that change in an upcoming commit. Having a list of "managers" in the WebIDL felt off to me, but at least we tried it out and decided it's a direction we didn't want to go in.
That is, I think we need to find a way to introduce this level of aggregation across wallets, because that's what the JS API "talks to", rather than directly to the actual [=holders=] up front. Am I making sense?
Yes, I think I get the general concern you're highlighting. Ignore the words I'm using for now, just trying to identify concepts... I believe you're identifying the "matching services" (the sandboxed WASM code), provided by each "credential provider" (digital wallet).
I was trying to avoid talking about those concepts in this PR (don't want the PR to add so much that it becomes a permathread and never gets merged because it's trying to do too much). Would it be okay if we introduced these concepts in a second PR? It seems orthogonal to the concept of a "credential provider"?
There was a problem hiding this comment.
(see suggestion about dropping "credential manager" entirely... that way we just side step this whole discussion, same as Cred Man does)
msporny
changed the title
index.html
Outdated
| establishing consent for the [=presentation=] of a [=digital | ||
| credential=]. Examples include a digital wallet, or a password manager, | ||
| that manages various | ||
| <a href="#credential-type-examples">credential types</a>. |
There was a problem hiding this comment.
Nit: we might want to <dfn> the "example credential types" just to avoid <a href=""> to them.
There was a problem hiding this comment.
Fixed in: 9ba5146
index.html
Outdated
| A protocol used for exchanging a [=digital credential=] between a | ||
| [=credential provider=] and a [=verifier=]. See section | ||
| [[[#protocol-registry]]]. |
There was a problem hiding this comment.
Maybe
| A protocol used for exchanging a [=digital credential=] between a | |
| [=credential provider=] and a [=verifier=]. See section | |
| [[[#protocol-registry]]]. | |
| Standardized data structures for [=presentation request|requesting=] and [=presentation response|receiving=] | |
| a [=digital credential=] between a [=credential provider=] and a [=verifier=]. See section | |
| [[[#protocol-registry]]] for supported protocols. |
There was a problem hiding this comment.
Hmm, there is more to a protocol than standardized data structures, no? Can we change "standardized data structures" back to "protocol", since "presentation request" and "presentation (response)" are the data structures. What about this?
| A protocol used for exchanging a [=digital credential=] between a | |
| [=credential provider=] and a [=verifier=]. See section | |
| [[[#protocol-registry]]]. | |
| A protocol used for [=presentation request|requesting=] and [=presentation response|receiving=] | |
| a [=digital credential=] between a [=credential provider=] and a [=verifier=]. See section | |
| [[[#protocol-registry]]] for supported protocols. |
There was a problem hiding this comment.
Hmm, there is more to a protocol than standardized data structures, no?
Yeah, you are definitely not wrong, but protocol is somewhat incomplete... the challenge with the formats is that we need to convert them to something that browsers can ingest, and it's unlikely those formats will define (JS compatible) error handling behavior, Web IDL conversions, etc.
So, what I was trying to convey is that the request can only be a data structure, the browser will do a bunch of security checks and conversion on that data structure (strip out any garbage, reject anything that looks suspect, etc.) and only then will it pass that to the platform (and then to a wallet).
There was a problem hiding this comment.
Right, but then what do we call OID4 or VC API or the "things" that define more than just "standardized data structures", but the order that those data structures are used in? Would something like this work for you @marcoscaceres? (I took your suggestion and added ", and the order in which those data structures are processed,":
| A protocol used for exchanging a [=digital credential=] between a | |
| [=credential provider=] and a [=verifier=]. See section | |
| [[[#protocol-registry]]]. | |
| Standardized data structures, and the order in which those data structures are processed, for [=presentation request|requesting=] and [=presentation response|receiving=] | |
| a [=digital credential=] between [=holder=] and [=verifier=] software. See section | |
| [[[#protocol-registry]]] for supported protocols. |
index.html
Outdated
| </dd> | ||
| <dt> | ||
| <dfn>Identity credential provider</dfn> | ||
| <dfn>Presentation request</dfn> |
There was a problem hiding this comment.
Maybe we don't need this... "exchange protocol" could cover both request and response. WDYT?
There was a problem hiding this comment.
It is helpful to separate the protocols from the formats, as some protocols can support multiple different types of formats. We know that we will have to refer to at least the following concepts in this specification:
- presentation request format (aka: query format)
- presentation (response) format (aka: digital credential format)
- presentation protocol (possibilities: browser-based, mDoc HTTP API, OID4, VC API, etc.)
We have also discussed these concepts in the WICG:
- issuance protocol (which might consist of "is your wallet appropriate for this use case?" presentation requests and responses over a presentation protocol or other metadata retrieval protocol)
"Exchange protocol" does cover everything, but it doesn't give us the terminology we need to speak more specifically to the classes of things that go into an exchange protocol.
There was a problem hiding this comment.
+1 to removing presentation request.
If the intention is to separate three things you list, manu, i think it is cleaner to use terms query language, credential format, exchange protocol respectively.
There was a problem hiding this comment.
I'd be hesitant to say "query language", as it seems to imply something like SQL. We are just passing a structure around, so, maybe, "query structure", or, just "query" (remember that in context it will be [=digital credential/query=]).
There was a problem hiding this comment.
I've made an attempt at using query in cd3dc63.
FWIW, "query" is what the Verifiable Presentation Request specification uses: https://w3c-ccg.github.io/vp-request-spec/#query-by-example
index.html
Outdated
| An application or service that provides a user interface for selecting | ||
| and/or querying a [=digital credential=], such as a digital wallet that | ||
| manages various identity documents and credentials. | ||
| A format that a [=credential manager=] uses, via an [=digital |
There was a problem hiding this comment.
| A format that a [=credential manager=] uses, via an [=digital | |
| A format that a [=holder=] uses, via an [=digital |
Isn't the response produced by the holder?
There was a problem hiding this comment.
I guess, yes... I was thinking the holder was a human... but, you are right that the holder is just the software.
There was a problem hiding this comment.
Hrm, no, I'm with @marcoscaceres on this one. The "holder" is a role that a human can play. Note that it doesn't need to be a human, it can be any entity that has agency such as an organization or AI -- which we don't need to talk about in this spec 'cause it'll just confuse people.
That holder uses software to achieve their goals, where the software is a "credential manager/provider" AND a "user agent" (they use both via this API) to achieve a specific workflow.
IOW, the response is provided by software, so we need to name that software. I do think "credential manager/provider" is the right term here. See See https://github.com/WICG/digital-identities/pull/83/files#r1504347853 for more detail on roles vs. software.
Thoughts, @samuelgoto?
There was a problem hiding this comment.
I see ... I always thought that the "holder" could also refer to the software, in addition to the individual ...
Would "wallet" (for the software that the "holder" uses) be incorrect/overloaded?
There was a problem hiding this comment.
Fixed in b080af4 by separating the concept of a "holder" from "holder's software" and adding an example of "digital wallet" for "holder's software".
index.html
Outdated
| credentials=] [[VC-DATA-MODEL-2.0]]. | ||
| </dd> | ||
| <dt> | ||
| <dfn>Credential provider</dfn> |
There was a problem hiding this comment.
I'll give "credential manager" a shot if we think that "credential provider" isn't going to work out.
"manager" is highly overloaded in Web Platform, and "credential manager", specifically means a lot of other things. "credential provider" isn't great, but I think is less ambiguous than "credential manager".
But also, I think we are missing one big architectural element here (speaking only for the choices that Android has made so far), which is that the [=user agent=] has a "registry" of all of the credentials from [=holders=] which it uses to build a cross-wallet credential selector. That is, I think we need to find a way to introduce this level of aggregation across wallets, because that's what the JS API "talks to", rather than directly to the actual [=holders=] up front.
Am I making sense?
| Is a [=verifiable credential=] about a person. | ||
| </p> | ||
| A cryptographically signed digital document containing one or more | ||
| [=claims=] made by an [=issuer=] about one or more [=subjects=]. |
There was a problem hiding this comment.
[=subjects=] is probably broader than we initially intended. for example, can a [=subject=] be a thing (rather than a person)?
do you feel that the original definition ("a digital credential is a [=verifiable credential=] about a person") is incorrect? it seemed like it would be useful to use that definition, that would then bring all of the other definitions (e.g. of [=claims=] and [=issuers=] transitively).
There was a problem hiding this comment.
Could a digital credential not be a [=verifiable credential=] about...
- a company?
- a pedigreed pet?
- a provenanced antique or artwork?
- a vehicle or other titled or registered asset?
There was a problem hiding this comment.
To @samuelgoto point, we were purposely trying to restrict this to claims about people. It might be good to go back to that and then broaden it in the future as we gain more implementation experience (or dare open this up to more types of documents).
There was a problem hiding this comment.
do you feel that the original definition ("a digital credential is a [=verifiable credential=] about a person") is incorrect?
Yes, as @TallTed mentioned, it's incorrect because "digital credential" and "identity credential" are about more than just people.
We could say "a personal credential is a [=verifiable credential=] about a person"... but then, like "identity credentials", if we start naming the WebIDL and parameters in the API around the concept of a "person" or "identity", we paint ourselves into a corner wrt. other digital credential types in the future (which we know there is interest in from the digital credentials ecosystem).
We could also say that "this specification is currently scoped to verifiable credentials related to people"?
I've made that change in 3813992. This allows us to focus on people in the spec, but allow for expansion into other things in the future. WDYT, @marcoscaceres, @samuelgoto, @TallTed ?
There was a problem hiding this comment.
"This specification is focused on digital credentials pertaining to people." is not quite "this specification is currently scoped to verifiable credentials related to people". "Currently" is key to this statement.
I would be mostly OK with "VCDMv2 is scoped to digital credentials related to people; future versions are expected to broaden their scope to include digital credentials related to other entity types."
That said, please note that the Traceability Vocabulary and Traceability Interop Work Items of the Credentials Community Group is focused entirely on VCs related to non-people. Changing the scope of the VCDMv2 as described above would appear to make the Traceability Task Force's output invalid until VCDMv3, or only valid with VCs based on VCDMv1. Both of these are troublesome, to my thinking.
There was a problem hiding this comment.
D'oh! Sorry. Too many interleaved specs on my workbench!
There was a problem hiding this comment.
(That said, "currently" is what was described here, but not what was implemented in 3813992. I think "currently" or similar phrasing should be applied.)
There was a problem hiding this comment.
Are we considering credentials that describe multiple subjects in the same credential here, as that appears what the definition implies? I know VC DM supports this, but it does bring about a whole different set of complexities and most other credential formats such as SD-JWT and mDocs have stayed away from this. I'd prefer we limit to one subject
| [=claims=] made by an [=issuer=] about one or more [=subjects=]. | |
| [=claims=] made by an [=issuer=] about a [=subject=]. |
That doesn't prevent the subject from being a thing, person or anything else it merely limits that a single credential is designed only to describe one subject which appears more reflective of what all the different credential formats share in common at the moment.
There was a problem hiding this comment.
A driving license is about multiple subjects: the issuer, the driver, and the vehicle classes the driver is allowed to operate.
There was a problem hiding this comment.
@TallTed your "currently" suggestion was implemented in 6859ed9 (by @marcoscaceres).
index.html
Outdated
| [=claims=] made by an [=issuer=] about one or more [=subjects=]. | ||
| </dd> | ||
| <dt> | ||
| <dfn>Credential manager</dfn> |
There was a problem hiding this comment.
can you help me understand why defining "Credential Manager" is necessary?
a couple of thoughts occurs to me:
- Credential Manager is already a term that is heavily used in this space (e.g. https://w3c.github.io/webappsec-credential-management/) and
- Given this specific definition that you choose, can't we just use the term [=holder=]?
There was a problem hiding this comment.
Yeah, that's a good point... maybe we don't need to define credential manager at all... or, we ask Cred Man to define it more formally and we link to it. As the credential manager itself deals so much with UI, I'd be ok to leave it undefined.
There was a problem hiding this comment.
I've removed the definition of "Credential Manager" in 08bd487 to try out the idea. Initial thoughts:
- It is possible to express what's in the specification currently using the term "holder" and "holder's software, such as a digital wallet".
- The language is a bit awkward in places w/o a specific term to use when discussing the concept of a "credential manager".
I think we can go with this for now, but we probably do need to talk about the concept of the browser mediating and the app/website that the request is finally handed off to. AS @marcoscaceres mentioned, maybe we just ask CredMan to define it and refer to that?
index.html
Outdated
| An application or service that provides a user interface for selecting | ||
| and/or querying a [=digital credential=], such as a digital wallet that | ||
| manages various identity documents and credentials. | ||
| A format that a [=credential manager=] uses, via an [=digital |
There was a problem hiding this comment.
I see ... I always thought that the "holder" could also refer to the software, in addition to the individual ...
Would "wallet" (for the software that the "holder" uses) be incorrect/overloaded?
Co-authored-by: Ted Thibodeau Jr <[email protected]>
Co-authored-by: Marcos Cáceres <[email protected]>
Co-authored-by: Kristina <[email protected]>
Co-authored-by: Marcos Cáceres <[email protected]>
Co-authored-by: Marcos Cáceres <[email protected]>
|
I've applied your suggestions @samuelgoto and @marcoscaceres. Please re-review. There are two remaining questions, one with a committed suggestion and another with a change suggestion that needs your feedback, @marcoscaceres: |
There was a problem hiding this comment.
This isn't quite perfect, but I think is a great starting point and baseline that we can work from! Thank you so much for putting this together @msporny and helping us find the words to express the main concepts!
Co-authored-by: Marcos Cáceres <[email protected]>
|
Applied your final "currently" change as well @marcoscaceres. |
|
Thanks again @msporny! You're a gem 💎! |
This PR attempts to align the terminology used in the Data Model section with language that is compatible with multiple digital credential ecosystems.
Preview | Diff