Align claims for Type and Status with JWT claims
danielfett opened this issue · comments
I think we should use short JWT-style names for the type and status list claims in order to show that these claims are at the core of the JWT (just like exp, iss, etc.). I therefore propose that we use scm (for "scheme", since the short form of "type" is already taken) and stu (for status list URI).
I don't think that this document is the right place for these things, as things should and are being described in the corresponding specification: https://github.com/vcstuff/draft-looker-jwt-cwt-status-list
If there a discussions on the claim names, this should happen over there
Hi.
Depends on the data model design/extension capabilities. There are 2 options:
a) This specification defines a claim (e.g., status/stu/...) as object with mandatory property type. Any other specification can then extend the claim, like the example in the previous comment
b) This specification does not define the status claim, other specifications define the additional claim etc.
With a) there's a better control over the data model and the approach is more interoperable, since the claim name is always the same, and the validation rules depend on the "type"/sub-type. In our projects, where we support several status methods (since there's no on-fits-all solution), this approach is more appropriate.
With b) every "status" specification needs to define their own data model (essentially), and there's always a risk that compatibility is broken; e.g., by setting required claims as optional, selecting different claim names, etc.
simplest definition would be (in terms of a JSON schema):
status:
description: >-
discovery of information about the current status of the credential, such as
whether it is suspended or revoked.
type: object
required:
- type
properties:
type:
description: >-
Claim that expresses the status type (and with it the vocabulary and the
validation rules) The type MUST be understood within the context of the
Trust Framework under which the credential has been issued. Type also
defines other optional/required claims.
type: string
@danielfett @tlodderstedt @paulbastian @awoie the design decision, whatever it is, should be applied consistently to all elements that can be extended according to this specification.
stu
I agree that status should be defined in https://github.com/vcstuff/draft-looker-jwt-cwt-status-list.
I'd not recommend using scm (or scheme) since this could be confused with JSON schemas (which might be a feature we could add in the future).
stu
I agree that
statusshould be defined in https://github.com/vcstuff/draft-looker-jwt-cwt-status-list.
This means option b) above?
the short form of "type" is already taken
FWIW it's not actually taken. "typ" is a registered JOSE header https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-header-parameters but not a registered JWT claim https://www.iana.org/assignments/jwt/jwt.xhtml#claims
"type" is already pretty short and JWT-style though. Don't necessarily need to change that one.
I started the very similar discussion here: oauth-wg/draft-ietf-oauth-status-list#21
@alenhorvat please take a look at the first draft of jwt status list
@paulbastian thank you for pointing out the issue and the status list documentation.
Indeed, the two are related. Here, the overall design decision should be addressed a) or b). Depending on that the JWT status list it will be clear how to bind it to this data model; via type or via claim name.
Does this make sense?
I would be fine with an external definition of the status list claim as its definition and contents may depend on the mechanim used.
I still think that a three-letter JWT-style claim instead of type would be good (but typ would be confusing).
I agree that typ is confusing for the credential type. What about dty which is short for Document Type?
Copying from a comment in related PR:
I worry about collisions and confusion with typ (and with cty) - those of us that work with this stuff will likely understand the difference, but there is probably a better descriptor we could use than type for this reason.
Maybe specifying "schema" or "schemaName" or "sn" (for nice short form) would be more useful here
Pretty strongly opposed to calling the property 'type' but think that the concept needs to be a property for sure
Also good with 'dty' as suggested above by @awoie
Just FYI
type is used in the JWT Embedded Tokens
Just FYI
typeis used in the JWT Embedded Tokens
Yeah - in that case I believe it is inside of token
We could also name it vct -> Verifiable Credential Type.
I'd prefer Digital Credential Type, then dct but I admit that I dream a world where the parameter names are self explanatory.
dog -> it's a dog
token -> it's a token!
even if we have the iat -> issued_at, that's good for me, but for the world I would give to my sons I would like issued_at.
Because once you have read it, you don't need to read the documentation, because the good semantic is self-documentationary. But coming back to the world of the conventions, I'd say
the loved ISO 18013-5 defines docType, and doctype is not so bad.
from Digital Credential Type (or Verifiable) I'd remove the first word, so Credential Type since the flow is digital ...
credential_type or dctype or vctype or whatever but the word type would be good to be there
we call the credentials verifiable credentials not digital credentials, so the claim should be 'vct' in my opinion.
This has been fixed by using vct in the PR linked above.