DIIP v5 #84
DIIP v5 #84
Conversation
…ft 08 to draft 13 and IETF Token Status List from draft 10 to draft 13
samuelmr
requested review from
TimoGlastra,
eklaver,
k00ij and
nklomp
as code owners
samuelmr
temporarily deployed
to
github-pages
GitHub Actions
Inactive
|
🚀 Preview deployment successful! 📄 Preview URL: https://FIDEScommunity.github.io/DIIP/pr/pr-84 This preview will be updated automatically when you push new commits to this PR.
|
samuelmr
temporarily deployed
to
github-pages
GitHub Actions
Inactive
samuelmr
temporarily deployed
to
github-pages
GitHub Actions
Inactive
samuelmr
had a problem deploying
to
github-pages
GitHub Actions
Failure
samuelmr
had a problem deploying
to
github-pages
GitHub Actions
Failure
samuelmr
temporarily deployed
to
github-pages
GitHub Actions
Inactive
spec/federation-profile.md
Outdated
|
|
||
| **Requirement: The Credential Issuer MUST use the value of the `credential_issuer` in its OID4VCI issuer metadata as its Entity Identifier.** | ||
|
|
||
| The Credential Issuer's Entity Configuration can be found by appending the string `/.well-known/openid-federation` to the Entity Identifier. |
There was a problem hiding this comment.
Shouldn't we point towards the method(s) listed under https://openid.net/specs/openid-federation-1_0.html#name-obtaining-federation-entity ? It is part of openid-federation, and adding this here could potentially deviate and/or confuse people
spec/federation-profile.md
Outdated
|
|
||
| The Credential Issuer MAY place additional metadata into the `federation_entity` Entity Type Identifier. | ||
|
|
||
| **Requirement: The metadata in the `openid_credential_issuer` property MUST override the metadata in the `federation_entity` property.** For example, if both `openid_credential_issuer.display.name` and `federation_entity.organization_name` exist, the Wallet MUST show the value of `openid_credential_issuer.display.name` as the name of the Issuer. |
There was a problem hiding this comment.
I'm still not sure what this is supposed to mean. organization_name and display.name have different semantic meanings according to the specification (https://openid.net/specs/openid-federation-1_0.html#name-informational-metadata-exte and https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#section-12.2.4-2.10.2.1).
In VCI we have for display.name
String value of a display name for the Credential Issuer.
In oidf organization_name is defined as:
A human-readable name representing the organization owning this Entity. If the owner is a physical person, this MAY be, for example, the person's name. Note that this information will be publicly available
It is even more confusing, as oidf does have a semantically similar claim display_name:
A human-readable name of the Entity to be presented to the End-User.
If we want to have either organization_name or display.name then it should not be for example but explicitly define that this particular property will be overwritten.
There was a problem hiding this comment.
I agree that we should remove the optionality and specify how all implementations should work.
(When I originally wrote the proposal, I was leaning towards just specifying priority/precedence rules for data coming from various sources. When the wallet needs to show the user "Org X is requesting information from your wallet", it could fetch the name of the requesting organization from any of the attributes listed above – even if they have different definitions.)
There was a problem hiding this comment.
Should we just require Issuers and Verifiers to populate display_name as specified in https://openid.net/specs/openid-federation-1_0.html#name-informational-metadata-exte amd Wallets to show that to the users?
There was a problem hiding this comment.
Or is it simpler to use openid_credential_issuer.display.name since that's what's being used if there is no OpenID Federation involved?
There was a problem hiding this comment.
OID4VCI metadata supports localization, but there seems to be no similar metadata for the Verifiers...
There was a problem hiding this comment.
Decided to use *federation_entity.display_name` in b3d496d.
spec/federation-profile.md
Outdated
|
|
||
| **Requirement: The Credential Issuer MUST place the OpenID4VCI issuer metadata into the Entity Configuration, in the `openid_credential_issuer` property.** | ||
|
|
||
| **Requirement: The Credential Issuer MUST place the public key material of the keys it uses to sign Digital Credentials in the `jwt_vc_issuer` property. The `jwt_vc_issuer` property MUST include the `jwks` property that contains the Issuer's JSON Web Key Set as defined in RFC7517.** (The `jwt_vc_issuer` property MUST NOT include the `jwks_uri` property.) |
There was a problem hiding this comment.
Suggest to call this vc_issuer and not jwt_vc_issuer.
See comment here: #79 (comment)
There was a problem hiding this comment.
And @samuelmr I think we should actually depend on the JWKS extensions from OpenID Federation instead of leaning on SD-JWT spec. And since we only allow jwks (for now), we can just mention that only jwks should be used for DIIP-compliant federations. But that doesn't mean an entity cannot use others. E.g. if you look at the federation spec:
It is RECOMMENDED that an Entity Configuration use only one of jwks, jwks_uri, and signed_jwks_uri in its OpenID Connect or OAuth 2.0 metadata. However, there may be circumstances in which it is desirable to use multiple JWK Set representations, such as when an Entity is in multiple federations and the federations have different policies about the JWK Set representation to be used. Also note that some implementations might not understand all these representations. For instance, while jwks_uri will certainly be understood in OpenID Connect OP metadata, signed_jwks_uri might not be understood by all OpenID Connect implementations, and so a JWK Set representation that is understood also needs to be present.
TBH we don't really use anything from the JWT VC Issuer of SD-JWT spec, since the resolving is handled by Federation, so we just leave the JWKS document, which is fairly common.
There was a problem hiding this comment.
So my suggestion:
- Do not lean on JWT VC Issuer from SD-JWT VC spec, but rather on the existing JWKs feature in OpenID Federation. There's a section on common metadata parameters and are perfect for what we're trying to do: https://openid.net/specs/openid-federation-1_0.html#name-extensions-for-jwk-sets-in-
- Optionally limit the common JWK parameters to only
jwks(so MUST be present) to simplify implementations. But not disallow the presence of other fields (to allow an entity to be part of multiple federations) - Rename the
jwt_vc_issuertovc_issuerto make it more generic (even though we define this profile for DIIP, I think we should think about application to non-DIIP credential formats and this is a very simple change).
cc @nklomp
|
@TimoGlastra, @eklaver, @k00ij, @nklomp: can you review the latest version so that we can publish it on Jan 15th as planned? |
|
Would it be possible that we publish DIIP on Jan 15 as a 'release candidate', and we give e.g one or 2 months of time to implement and gather feedback and make adjustments based on that. Since no one already has this implemented on day one, I think giving a window to iterate on the document makes sense, and it gives implementers a heads up that things may change if they were incorrect. It's not intended to be used to push new features |
This PR updates the OID4VC, SD-JWT VC, and Token Status List versions.
It also adds OPTIONAL requirements for issuer and verifier agents to support OpenID Federation (publish Entity Configuration files).
This version includes a draft of OpenID Federation Digital Credentials Profile – likely to be carved out as a separate specification in the future.