How to choose `type` values for your credential format?
danielfett opened this issue · comments
We need to give guidance in the spec on choosing type values for a credential format.
We need to think about collision resistance - either by a registry or something DNS-based like URIs or java package name notation.
Personal opinion: Use URLs, like XML namespaces. It automatically avoids collisions, there is no registry required for potentially large amounts of values, and we can think about extending this in the future with machine-readable information about credential format.
@selfissued suggestion is worth consideration: to have a registry and recommend that the type value either be a registered value or be a collision-resistant value.
My suggestion would be to recommend either registering values in a registry that we create as community service and/or to use collision-resistant names, as defined at https://www.rfc-editor.org/rfc/rfc7515.html#section-2. In particular, if we make a recommendation for using some form of collision-resistant names, we should just cite RFC 7515's definition and not create our own that is similar but different.
How to choose type values
Use URLs, like XML namespaces. It automatically avoids collisions, there is no registry required
Sounds a bit like you are re-inventing (parts of) JSON-LD :)
How to choose type values
Use URLs, like XML namespaces. It automatically avoids collisions, there is no registry required
Sounds a bit like you are re-inventing (parts of) JSON-LD :)
Only the requirement that type might have to be a URL bit. JSON-LD is an RDF implementation and therefore has more boilerplate that is not needed that goes beyond this problem.
This PR introduces the requirement for identifiers to be Collision-Resistant Names: #173
I still think that moving towards an identifier format that will later allow discoverability of credential rules and policies would be beneficial. For that, I think that URIs would be most useful, as explained above. There is a ton of information that Holders and Verifiers might want to be able to discover:
- What kind of binding is employed for a certain credential type (see #145)
- More generally, what data can or cannot be used for checking the holder binding.
- Information about credential types (e.g., display names, colors, logos, etc.) — this clearly overlaps with what is transported by OpenID4VCI today
- A schema for content verification, including what can or cannot be made selectively disclosable
- Information about individual data fields (e.g., the human-readable label for a claim name, including its translations)
That kind of discoverability could be pointing to or just contained in a human readable spec or document that has that kind of information.
The PR has been merged, but let's use this issue to discuss whether we need discoverability.
@bc-pi That's correct, URLs enable discoverability, but that doesn't mean that they are the only option.
The PR has been merged
I'm not familiar with IETF processes, but merging such breaking changes in less than 24 hours without any chance of community review feels a bit ... hmm ...
The PR is a relatively small change, and as indicated by my comment above, it is probably not the last word in this regard. I think we need to draw the bigger picture on what we expect from "credential types" and then think about how that needs to be reflected in the draft.
But, more generally, the IETF process is not designed around anything that happens in this git repository at all; what counts is consensus on the mailing list (both immediate discussions for larger normative changes as well as the working group last call, which can introduce substantial changes as well). Draft versions are a tool to get feedback from the working group including on smaller changes that have not been discussed on the mailing list beforehand.
The new draft version that we plan to release in the next days will be announced both on the mailing list as well as during the in-person meeting in Prague shortly after. If we receive feedback indicating that there is no consensus for a certain choice we made, we will respect that and modify the next draft accordingly. In that sense, having the PR merged is just a means to get feedback on a small step towards a solution.
I am not in favor of a registry. We (Block) are interested in sd-jwt-vc for its simplicity, and would leverage the property to point to JSON Schema documents.