Replies: 17 comments 16 replies
-
|
In openid/federation-wallet#51, I added a missing aspect to the Wallet Architectures spec, trying to define how trust is established between the verifier and the issuer. |
Beta Was this translation helpful? Give feedback.
-
|
Some time ago, I proposed the did:oidf DID method. I still believe that method might be useful for ecosystems that want to use OpenID Federation as the trust establishment layer. To succeed, the method should see some implementations or at least interest from some vendors to implement it. Might be a chicken/egg problem... |
Beta Was this translation helpful? Give feedback.
-
|
What we currently lack:
Do we agree that these are the main functional requirements? |
Beta Was this translation helpful? Give feedback.
-
|
If the issuer and verifier were identified by plain HTTPS URLs, it would be trivial to get their Entity Configuration files. In the DIIP community, we want issuers and verifiers to be identified by DIDs. The The main author of the OpenID Federation Wallet Architectures wasn't keen on introducing additional discovery mechanisms in that spec. |
Beta Was this translation helpful? Give feedback.
-
|
The second Implementor's Draft of OID4VP included the section 10.2. Support for Federations/Trust Schemes with an example: {
"termsOfUse":[
{
"type":"<uri that identifies this type of terms of use>",
"federations":[
"<list of federations/trust schemes the Credential Issuer asserts it is a member of>"
]
}
]
}This section is removed from the subsequent versions of the specification. It would be a nice way to refer to the federation from a credential, but it is somewhat tied to W3C VCDM credentials (1.1 or 2.0). The same structure could be used in SD-JWT VC credentials, but we would need a specification to define the behaviour. If the OpenID Federation Wallet Architectures maintainers are reluctant to include additional discovery mechanisms into that document, what would be the correct place to define the |
Beta Was this translation helpful? Give feedback.
-
|
With the help of Claude, I drafted a proposal for a specification that defines how DID Documents can be used to point to OpenID Federation Entity Statements. See https://claude.ai/public/artifacts/d619613b-4506-4140-b21b-b5e64fc3fc3b Using the DID document to reference OpenID Federation means that we didn't need to change the credential format specifications, or the credential protocol specifications, or the OpenID Federation specifications in any way. This would be limited to DIDs. If there is interest in advancing this, we still would need a body to host this specification. Would DIF be a good home? |
Beta Was this translation helpful? Give feedback.
-
|
The DIIP Meetup on October 30th discussed that the support for OpenID Federation could be added as an optional requirement to DIIP v5. |
Beta Was this translation helpful? Give feedback.
-
|
My proposal in today's call: DIIP v5 requires that DIIP-compliant issuers must publish their OpenID Federation Entity Configurations, and DIIP-compliant verifiers must be able to resolve the trust chain (perhaps using an existing There would be no requirements for wallets, but they could optionally use the issuer's Entity Configuration to support the holder's trust decisions. DIIP v6 would then require verifiers to publish their Entity Configurations and wallets to support OpenID Federation to establish trust to both issuers and verifiers. |
Beta Was this translation helpful? Give feedback.
-
What is defined:
What is missing:
Initial thoughts about the issuer's configuration
Initial thoughts about the content of the subordinate statement about the issuer
Initial thoughts about the verifier's configuration
Initial thoughts about the content of the subordinate statement about the verifier
Initial thoughts about the discovery of the issuer's configuration by the verifier
|
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
@samuelmr OIDF4WA chapter 7.1 provides an example of verifier Entity Configuration where, as I interpret it, the intent is to 1-on-1 copy the verifier OpenID4VP metadata into the "openid_credential_verifier" claim.
However, in e.g. OIDfed 5.1.2. The specification showcases OP Entity Configuration which duplicates parts of the OP metadata which could also be discovered if OIDC Discovery was being used. That is also what you are showing in your last example the benefit of this approach is we have more control over various part of the metadata, but at the same time we will have to duplicate several elements already found in the OpenID4VP/VCI |
Beta Was this translation helpful? Give feedback.
-
The assumption here being that the wallet should enforce that? Or at least warn if there is a mismatch? I agree this capability would be very powerful especially from legal perspective, yet at the same time I am wondering/worrying how complex that would become. Generally speaking OIDfed has the Metadata Policy capability, which is I think intended as away to technically enforce superior policy on subordinate entities. I am no so sure however if it was ever envisioned as way to express a policy in such detail as would be needed here. As an alternative could we in some way use DCQL here? This would allow the TA to very clearly specify as DCQL is rather rich in its capabilities. It would also be very easy to test for a wallet as it could just directly compare the incoming DCQL from the verifier with the info from the TA. We could probably express the TA credential requirements in a new claim or better perhaps in a novel "additional operator" as described in OIDFed 6.1.3.2 |
Beta Was this translation helpful? Give feedback.
-
Would that work?
In vanilla OIDfed that is the issuer (iss). If we mandate iss == credential_issuer, is this then not resolved?
Would also work for me |
Beta Was this translation helpful? Give feedback.
-
|
Based on the discussion yesterday, would the following specification be sufficient to implement OpenID Federation in wallet use cases: IntroductionThis specification profiles OpenID Federation [OpenID.Federation] for use with digital credentials, specifically focusing on credential issuance via OpenID for Verifiable Credential Issuance [OID4VCI] and credential presentation via OpenID for Verifiable Presentations [OID4VP]. The profile simplifies federation usage by limiting scope to trust chain resolution and metadata discovery, while omitting more complex features such as federation policies and trust marks. ScopeThis profile applies to:
This profile does NOT apply to and does NOT require conforming implementations to support:
Notational ConventionsThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. TerminologyThis specification uses the terms defined in OpenID Federation [OpenID.Federation], OpenID for Verifiable Credential Issuance [OID4VCI], OpenID for Verifiable Presentations [OID4VP], and SD-JWT VC [I-D.ietf-oauth-sd-jwt-vc]. Entity Identifier: As defined in OpenID Federation, a URL that uniquely identifies a federation entity. Entity Configuration: As defined in OpenID Federation, a signed JWT published at the Entity Identifier's Trust Chain: As defined in OpenID Federation, a sequence of Entity Statements from a Leaf Entity through intermediate entities to a Trust Anchor. Issuer: The role of the entity issuing credentials as defined in [VC-DATA-MODEL-2.0] Credential Issuer: The technical service used to issue credentials as defined in [OID4VCI] Verifier: The entity that requests, receives, and validates Presentations as defined in [OID4VCI]. Note that this specification does not distinguish the role and the technical service of the verifier the same way it does for Issuer and Credential Issuer. For the purposes of this specification Verifier may refer to either the role or the technical service. (Thus, the reference to the definition in [OID4VCI] and not the one in [OID4VP].) Credential IssuanceEntity IdentifierThe Credential Issuer MUST use the value of the The Credential Issuer's Entity Configuration can be found by appending the string Metadata PublicationThe Credential Issuer MUST place the OpenID4VCI issuer metadata into the Entity Configuration, in the If the The Credential Issuer MAY place additional metadata into the The metadata in the Example: Credential Issuer Entity Configuration{
"iss": "https://credential-issuer.example",
"sub": "https://credential-issuer.example",
"iat": 1616239022,
"exp": 1616239322,
"metadata": {
"federation_entity": {
"organization_name": "Example Credential Issuer",
"contacts": ["[email protected]"]
},
"openid_credential_issuer": {
"issuer": "https://credential-issuer.example",
"display": [
{
"name": "Example Issuer",
"locale": "en-US",
"logo": {
"uri": "https://credential-issuer.example/logo.png",
"alt_text": "Example Logo"
}
}
],
"credential_issuer": "https://credential-issuer.example",
"authorization_endpoint": "https://credential-issuer.example/authorize",
"authorization_servers": ["https://credential-issuer.example/authorize"],
"credential_endpoint": "https://credential-issuer.example/credential",
"credential_configurations_supported": {
"sd_jwt_vc_example": "..."
}
},
"openid-configuration": {
"jwks_uri": "https://credential-issuer.example/jwks"
}
},
"jwks": [
{
"kty": "EC",
"kid": "MJ2BW-rNshp9sjh3SvwnBIkEsYsU92xVtC3-Fv_lcKc",
"alg": "ES256",
"crv": "P-256",
"x": "JTEE5QghmkA_-7_pZoKIluRzGNvQGtzmpNvb_nAswhE",
"y": "A_iBfIseHsdfE7CmI3lIYtKMdfyXXOIpPX_o6O0h0wY",
"use": "sig"
}
],
"authority_hints": [
"https://trustregistry.example"
]
}SD-JWT VC CredentialsWhen the Issuer issues credentials in the SD-JWT VC format [I-D.ietf-oauth-sd-jwt-vc], the Issuer MUST place its Entity Identifier in the Example: SD-JWT VC with Federation ClaimThe following non-normative example shows a decoded payload of an SD-JWT VC credential with the {
"iss": "https://credential-issuer.example",
"fed": "https://credential-issuer.example",
"iat": 1683000000,
"exp": 1883000000,
"vct": "https://credentials.example.com/identity_credential",
"is_over_65": true,
"address": {
"street_address": "123 Main St",
"locality": "Anytown",
"region": "Anystate",
"country": "US"
}
}W3C VCDM CredentialsWhen the Issuer issues credentials in the W3C Verifiable Credentials Data Model format [VC-DATA-MODEL-2.0], the Issuer MUST place a Example: W3C VCDM Credential with termsOfUseThe following non-normative example illustrates the use of the {
"@context": [
"https://www.w3.org/ns/credentials/v2"
],
"id": "urn:uuid:c65d364e-2560-4e08-be03-9c3d944d609d",
"type": [
"VerifiableCredential"
],
"issuer": "did:web:credential-issuer.example",
"validFrom": "2025-12-01T00:00:00Z",
"validUntil": "2028-12-31T23:59:59Z",
"credentialSubject": {
},
"termsOfUse": {
"type": "OpenIDFederation",
"trustFramework": "Example Federation",
"policyId": "https://credential-issuer.example"
}
}Note on Credential Issuer vs. IssuerThe Issuer defined in the digital credential (the value of the For example, the OpenID Federation Entity Identifier of the Issuer of the credential could be If the Issuer chooses to make this kind of distinction between the entity issuing the credential and the technical service used for issuance, it is RECOMMENDED that the Entity Configuration of the technical service has an Credential Presentation and VerificationClient Identifier SchemeThe Verifier MUST use the Metadata PublicationThe Verifier MUST place verifier metadata into the Entity Configuration, in the Trust EstablishmentTo establish trust with the issuer (ensure that the issuer can be trusted), the Verifier MUST resolve the Trust Chain from the issuer's Entity Configuration until it finds a Federation Entity it trusts. Example: Verifier Entity Configuration{
"iss": "https://credential-verifier.example",
"sub": "https://credential-verifier.example",
"iat": 1616239023,
"exp": 1616239323,
"metadata": {
"federation_entity": {
"organization_name": "Example Credential Verifier",
"contacts": ["[email protected]"]
},
"openid_credential_verifier": {
"jwks": {
"keys": [
{
"kty": "EC",
"crv": "P-256",
"x": "f83OJ3D2xF4Z1s3QpLQe4qVb8K7q6y1v3z4Yb6k9J0",
"y": "x_FEzRu9q3u4bWz5n9X2L4q1U8T7c6v5s2d1a0b3C4",
"alg": "ES256",
"use": "enc",
"kid": "ec-key-1"
}
]
},
"encrypted_response_enc_values_supported": [
"A128GCM",
"A192GCM",
"A256GCM"
],
"vp_formats_supported": {
"dc+sd-jwt": {
"sd-jwt_alg_values": ["ES256"],
"kb-jwt_alg_values": ["ES256"]
}
}
}
},
"jwks": [
{
"kty": "EC",
"kid": "y4nC8uTvcM5uJxOIvUqFjXb2EA6xPGdnt8zvjW94m6U",
"alg": "ES256",
"crv": "P-256",
"x": "K6dA9ayt4P8xBN6SFiCZYOI2qeaFda7VV5wnmHWcl7w",
"y": "CdE30dUX0geK4NL8IMC9u-rRMOLC9WaScJIGK5rxtKI"
}
],
"authority_hints": [
"https://trustregistry.example"
]
}Subordinate StatementsIntermediaries and Trust Anchors MAY authorize their subordinates to issue or request certain credential types by placing metadata values like The meaning of such statements SHOULD be specified in ecosystem rulebooks and is out of the scope of this specification. |
Beta Was this translation helpful? Give feedback.
-
|
@TimoGlastra's comments #15105343 and openid/federation-wallet#48 (comment) got me re-thinking about the discussion we had related to the Issuer as a legal entity and the Credential Issuer as a technical service. I still think that it makes sense to keep that distinction so that an authority (a federation Intermediary or Trust Anchor) can make statements about the status of legal entities without the need to validate each technical service they are using. On the other hand, if the Issuer and the Credential Issuer are separate entities, I suppose both would need to include the same key (the one used to sign the credential) in their Entity Configurations. |
Beta Was this translation helpful? Give feedback.
-
I would add: "at this time" |
Beta Was this translation helpful? Give feedback.
-
NOT is not BCP 14 [RFC2119] [RFC8174], so I suggest to reword to: |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Let's use this discussion thread to define how the DIIP-compliant wallets and agents should use the OpenID Federation specification.
Links:
Beta Was this translation helpful? Give feedback.
All reactions