I-D.terbu-sd-jwt-vc doesn't support OIDC Federation

[peppelinux]

I-D.terbu-sd-jwt-vc doesn't support OIDC Federation, that's a webpki with trust chains and a solid alternative to X.509

Originally posted by @peppelinux in #56 (comment)

Torsten's reply:
nothing in the sd-jwt vc draft precludes use of OIDC Federation, in the same way as it does not preclude x.509
HAIP mandates jwt issuer and x.509, adding another (mandatory to implement) option seems a complexity driver, but let's talk. Please open an issue about it as this PR is about a different topic.

[Sakurann]

We do not have an agreement to use OpenID Federation in HAIP right now. and I am honestly very reluctant to add it. X.509 approach does not need OIDC.Fed. and web PKI approach does not either, because it can be used together with a trusted list of Issuers/Verifiers and it is simpler then establishing the whole OIDC.Fed.

[peppelinux]

I never understood why, honestly.

X.509 approach attests keys, as webPKI does. Federation attests metadata and trust marks as well and give a distributed approach to implement trusted lists.

I have the fear that the pursuit of simplicity is reducing the functionality and requirements that will be needed later and then it will require custom extensions in X.509.

Last but not least, the requirement of non-repudiation of the public keys published, which cannot be achieved with a webpki that offers keys in plain text.

It's easier to work with new generations of developers using JWT than X.509, it's easier to build a trust mark and use it as a long lived attestation, than to bloat X.509 with things it wasn't meant for. This is a though also in terms of design of the solution

[fmarino-ipzs]

Personally, I do not see any opposition between a pki x.509 and federation, nor any full overlap. On the contrary, federation is a well defined framework that allows for key attestation (possibly even using a pki x.509) and secure exchange of metadata (in addition to other useful features such as policy and trust marks). If such a framework is available, it should at least be considered as an option in a high assurance profile, even if it is more difficult to implement. They are not exactly the same thing: federation is more than a x.509 pki.

As you know, we have already adopted federation in the Italian eID implementation profiles and we are planning to use it also for the national wallet solution as we consider very useful. And I am convinced that the adoption of federation will increase in the future.

[paultempleman]

I think @peppelinux makes an important point that we are talking about where is the "Federation attests metadata and trust marks" - in other words where should the meta data around the issuer and verifier be stored. In the GAIN POC the term "Trusted Network" is used. Additional meta data around issuers and verifiers (e.g. who is the organisation behind the issuer, verifier, who is privacy controller etc,) is going to be extremely important especially to create that "Trusted Network" especially for regulated industries and as governments increase regulation of digital platforms.

I do think there are going to be different technical standards in this area emerge on how to create that trust both within and identity ecosystem/trust framework and between identity ecosystems/trust frameworks - including Government mandated standards - so I can see why there is debate over a particular standard being specified.

Since this working group is focused on the issuer-holder-verifier, perhaps a way around this is to use the term "verifiable data registry" and add "verifiable data registry" column in 3.3. Standards where we already mention Issuer, Wallet, Verifier - which would allow us to specify which of the standards does the verifiable data registry" need to adopt. This would allow us to add competing standards such as OIDC.Fed, pki.x509 etc. as a MAY in that fourth column. This would at least give implementers on what the alternative approaches are available to be used when implementing this group of specfications.

I also not that the GAIN POC is currently referring to OpenID4IDA and OIDC.Fed within their work as a "Discovery and Trust" "Control Plane" and therefor there is logic in @peppelinux referring to OIDC.Fed.

Would creating a fourth column "verifiable data registry" column in 3.3 and adding a row for OIDC.Fed with MAY in the fourth column be an acceptable path forward?

It may also be useful to add additional row in 3.3 for OpenID4IDA with a value of OPTIONAL.

As one of the key audiences of this specification is implementors of this group of standards I this it is important to provide guidance on what standards are available for implementors to choose on how and where that meta data should be created in order to create "trust" within the ecosystem.

Whilst on the topic of identity trust, OIX comment "For many types of transaction, digital or otherwise, organizations need to know who they are dealing with and what that person is able, or eligible, to do. The rise of Identity Theft means that organizations cannot rely on a person simply claiming to be who they are, independent verification and risk checks are required. Equally, genuine individuals may try to present false information about themselves in order to gain access to goods, services or environments that they do not have the eligibility for."

They are talking about an organisation being able to trust the individual. But they also miss the point that individuals also need to be able to trust the organisation (including the digital services they offer). As privacy regulation globally continues to shifts to protect the individual this meta data is going to be needed not only for the issuers and verifiers but also for the holder.

[leifj]

I will put on my R&E hat and say that we do not believe a "pure" X.509 approach has a chance of working. Single hierarchy trust has been shown not to work many times over the last 20+ years when research and higher education has been operating trust infrastructure. As soon as the EU wallet goes beyond the very limited usecase of BA, MA and PhD degrees and start to involve research collaborations etc, single hierarchy (including trust status lists) models break down. We have ample experience that clearly show this to be true. For a quick introduction cf my blogpost at medium https://medium.com/@leifj/trust-does-not-scale-94bab5b67f5c. Note the example based on LIGO which isn't even close to unique - there are tons of these research infrastructures, each of which represent critical research and none of which is able to represent their trust requirements in a single hierarchy PKIs.

For the record: in R&E we are currently operating multiple interconnecting and overlapping trust federations with an excess of 20k services and organizations - globally (not just EU) and cross border.

Maybe the argument is that the EU digital wallet won't support research but I seriously doubt this is the intent. In order to support the complexity we have today we will need the features present in OpenID federation - in fact we (as a community of trust operators) designed OpenID federation to reflect the complexity we have.

[jogu]

This issue should probably be raised under https://github.com/oauth-wg/oauth-sd-jwt-vc instead?

[peppelinux]

OpenID Federation is cited in the ARF v1.3, within the section about how an RP evaluates the trust with a VCI, in relation about how a public key can be provided, here:

https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/blob/main/docs/arf.md#6322relying-party-trusts-provider

[Sakurann]

great discussion, but please raise it under ttps://github.com/oauth-wg/oauth-sd-jwt-vc instead.