HTTPS URL and OIDC Federation?

[Sakurann]

per comment from @peppelinux, consider mention that an issuer URL used for /.well-known/jwks can also be used for OpenID Federation.

[peppelinux]

OIDC Federation is related to the technical implementation of the Trust Model and then to the infrastructure of Trust

an HTTP URL should, or may, be inspected for Trust Assessment with the .well-known/openid-federation endpoint and then with the Federation Entity Discovery process.

The Federation Entity Discovery process is always required when the trust assessment method is OpenID Federation and its Trust Chain contains all the verifiable trust relationships between the parties, the metadata with policy applied and everything about a subject

If the Trust Chain is statically available, it just only be validated and checked against the revocation methods of the participants in the infrastructure. This last statement considers the availability of the Trust Chain of every issuer of JWS, as introduced in the issue below:

#33

A secure Trust Model requires "signature everywhere" to satisfy the requirement of non-repudiability or everything issued by an issuer. For this reason the JWKS in OpenID Connect federation are embedded in the signed metadata (Entity Configuration) or made available, and signed, in the signed_jwks_uri

toghether with the federation entity discovery and the provision of static trust chain in the JWS header, I'm working on these two DID resolution methods

did:openid:example.it:oidc:rp[#$kid-value]
this URN is translated to https://example.it/oidc/rp/.well-known/openid-federation and requires a Federation Entity Discovery to build a valid Trust Chain. This doesn't preclude any other OpenID Connect trust resolution method in the present or in the future, giving to the trust resolver the freedom to decide which openid standard to use for the resolution of the keys. Kid value is optional depending to the scope of the did indetifier, if related to a subject or to a key

did:openid-trustchain:BASE64({"kid": 1, "trust_chain": [ ... ]})
this URN is translated to a static OpenID Connect Federation Trust Chain, that gives a snapshot of the federation configuration and of the trust relationships between the subject and the Trust Anchor, its metadatas, the metadata policies, trust mark... Everything about the Trust Model, without any federation entity discovery process

So, HTTP or DID a Trust Model with OpenID Federation should be always supported in the specs

[tlodderstedt]

The .well-known/jwt-issuer mechanism works with any other .well-known location. We should give a couple of examples.

Regarding OpenID federation, I’m not sure the current revision of the specification would work well with it, given it would require the issuer keys used to sign JWTs to turn up in the entity configuration again (which duplicates the data).

@peppelinux can you please comment on that?

[peppelinux]

I start over from the requirements I have regarding the long-lived and non-repudiable attestations.

a. An Attestation can be a VC or any kind of signed artifact issued according to a contract.
b. The contract can be bilateral, between two organization or multilateral if we mix thousands of organizations and natural persons according to a defined Trust Model, since the architecture is decentralized I consider only multilateral relationships.

The Attestation must be verified in both online and offline flows, this requires that the following statements must be satisfied:

1. The public key for verification must be attested as reliable by a Trusted Third Party. This implies that the public key MUST be contained in the Attestation together with the proof of its reliability. The reliability proof must be issued by a Trusted Third Party
2. The verifier must verify the digital signature of the attestation, using the public key contained in it, since the public key is signed by a Trusted Third Party and made available in the signed attestation
3. The state of the issuer must be contained in the attestation, since all the information about the issuer is available statically and signed by a Trusted Third Party
4. The Policy regarding the issuer MUST be applied, to give evidence if the issuer behaved correctly at time of issuance
5. even if the public keys may change in the future years, the state of the issuer at the time of the issuance, the applied policies, its jwks, must be always verifiable, since the attestation cannot be repudiated

consider that an issuer of an attestation can be one or more of all the following entities:

I. Wallet Provider issuing a Wallet Instance Attestation
II. Credential Issuer that issues a VC
III. RP that issues a presentation request
IV. Wallet Instance that issue a signed presentation request or an id token

All these requirements are fully satisfied by OpenID Connect Federation Trust Chain, since the JWS trust_chain is going to be registered in the IANA JWS header parameter register.

The sole and particular exception is made for the Wallet Instance, since these are not andled by organization but by natural person. In this cases they must present the Wallet Instance Attestation where the Wallet Provider Trust Chain is contained in it. A verifier trusts the wallet instance using the instance attestation, since the trust to the Wallet Provider can be established, statically and in offline flows.

The Trust Chain contains all the components listed below:

• Trust Relationship of the subject (one of the previously listed above entities) with a Trusted Third Party, considering all the entities along the path from the subject to a well-known Trust Anchor. If any available, these are called Trust Intermediates
• The Metadata of the subject at time of the issuance
• The Trust Marks/Compliance-attestations of the subject at time of the issuance
• The Policies published by Trust Anchor and its Intermediates to be applied to the issuer Metadata
• The public keys related to the issuance protocol
• the public keys related to the Trust Model attesting the Trust Relationship and the non revocation of the issuer at time of the issuance

It can be validated using the sole public key of the Trust Anchor.

All this, that's a lot, is efficiently contained in the Trust Chain, that's a JSON Array of JWS. Each JWS is binded with its siblings by claims, public keys and signatures. Using JWS singed with EC, I still don't have a comparison with X509 in term of storage but it is not small at all. But the point is not the size, but the features and the capabilities we have in the Trust Chain instead of the X509 certificate chain.

Finally the answer to your question is:

Since the public keys are not duplicated because they are self contained in the Entity Configuration (.well-known/openid-federation) and validate through the Trust Chain, the data doesn't require to be duplicated elsewhere

And I want to continue discussing the requirement of external endpoints for JWKS, below.

OpenID Connect Federation enables the signed_jwks_uri, then .well-known/jwks can be pointed by this claim, with the sole requirement that its response must be signed, for the highest level of security of the Trust Model

The traditional approach based on TLS doesn't give non-repudiability of the attestations, since the jwks may change in the future and since these endpoints are not available in offline flows

While TLS alone may work fine in the traditional digital identity infrastructure, where the trust is prestablished between an RP and an IDP, differently the Identity Wallets requires other paradigms regarding the Trust Establishment, where the concept of scalability, distribution and decentralization should consider how fundamental are the long lived static attestation of trust and how the "decentralized storage" requires the trust attestation to avoid the architectural need of a single registry with the historical information about all the issuers

[tlodderstedt]

Since the public keys are not duplicated because they are self contained in the Entity Configuration (.well-known/openid-federation) and validate through the Trust Chain, the data doesn't require to be duplicated elsewhere

If I understand your answer correctly, you say that .well-known/openid-federation is an alternative to .well-known/jwt-issuer, right?

[peppelinux]

Yes, definitively a different approach

The solution is the one that satisfies all the requirements and represents the best solution

while the alternative should map the implications that entails in relation to the requirements

[awoie]

After a discussion on the editor's call, we decided to close this issue.

The VC-SD-JWT spec does not define every possible mechanism how to obtain the public key to perform issuer authentication, i.e. verify the signature of the JWT. It intentionally says that other mechanisms are supported that are defined outside of this specification. One such mechanism is using OIDC Federation. If there is a need to define how OIDC Federation can be leveraged to verify the SD-JWT, then this should be done in the OpenID hi-assurance profile.