-
Notifications
You must be signed in to change notification settings - Fork 9
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
Align Model terminology with multiple digital credential ecosystems. #83
Merged
+45
−26
Merged
Changes from all commits
Commits
Show all changes
18 commits
Select commit
Hold shift + click to select a range
337093d
Update model to align with existing digital credential terminology.
msporny b1db9ae
Update to use "exchange protocol" references.
msporny da0ad7c
Fix grammar and accuracy in Model section.
msporny 40d8a45
Rename "password" to "login" manager.
msporny f9d4b22
Add DFN for example credential types.
msporny 601fa3f
Tie "Exchange protocol" terminology to "digital credential" domain.
msporny 6b91548
Remove local biblio entry for ISO18013-5.
msporny 8faa1ae
Change definition discussion to note.
msporny 5440c60
Change "secured" to "signed".
msporny 8fe47bd
Remove references to external specifications.
msporny 50a2b3a
Attempt to use `query` instead of `presentation request`.
msporny 0f4ad56
Change "credential provider" -> "credential manager".
msporny 1e6c572
Note focus on digital credentials about people.
msporny 9e8500e
Remove definition of Credential Manager.
msporny e162c9e
Specify that formats are used by software.
msporny b49eadf
Change "Presentation" to "Presentation response".
msporny b080af4
Clarify holder software/digital wallet, uses presentation response.
msporny 6859ed9
Note current specification focus on people.
msporny File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[=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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could a digital credential not be a [=verifiable credential=] about...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
D'oh! Sorry. Too many interleaved specs on my workbench!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@TallTed your "currently" suggestion was implemented in 6859ed9 (by @marcoscaceres).