[Federation] Aligning trust_framework, verifier attestation, other signer/issuer/verifier related attributes

[Alen Horvat]

Hi.

In summary: different standards propose different ways to transport credential signer or issuer data.

Goal is trying to align the different initiatives to use the same transport mechanism for trust chains, attestations.

Related issues:

• https://github.com/lovele0107/signatures-conformance-checker/issues/41
• https://github.com/openid/OpenID4VP/issues/36#issuecomment-1702545905

Proposal is to re-use the design of ETSI JAdES where trust chain/entity statements can be transported in the signer attribute JOSE header claim. Note that design supports both embedded and referenced attributes.

Furthermore, as outlined in the github signature conformance checker discussion above, the proposal is fully JAdES compliant which means it can cater for all 4 signature profiles (B, L, LT, LTA). We tested it against the JAdES JSON schema, reviewed and tested the approach against the specification, and we also ran test against the JAdES conformance checker.

The only thing that would change is updating the text wrt the trust_chain JOSE header claim.

What is the opinion of the WG?

Note: same proposal has been made for the newly introduced “Verifier Attestations” in the OID4VP specifications.

[Giuseppe De Marco]

We don’t have discussed this within the WG yet.

OIDC Fed defines what’s the trust chain, how to obtain it, its format, how to validate and how to derive a protocol specific final metadata, when required. The Federation Trust Chain this might be carried in the JWS header parameter as defined within the specs but nothing prevent the born of new specs or approaches where a federation trust chain might be carried, in its original format, in other kind of artifacts, like the proposal below

https://peppelinux.github.io/draft-demarco-cose-header-federation-trust-chain/draft-demarco-cose-header-federation-trust-chain.html

I’d go for specialized drafts for specialized tecnologies/approaches and ecosystem, as the link above is intendend for the COSE Sign Document

[Nat Sakimura]

Please participate in the discussion.

[Alen Horvat]

I understand @Giuseppe De Marco , and I acknowledge that the proposal you’re making is perfectly fine. However, if you check the example below, you’ll see that the same structure enables transporting a wide range of issuer attributes/credentials even in different formats from different trust frameworks.

{} stand for placeholders. The same structure is also used to transport additional x509 certificates when required.

I put multiple different formats to exemplify the possibilities.

Note that the only change for OIDC Fed is going from trust_chain → srAts.SignedAssertions → qVal object

For closed systems, this is overkill, but for interoperable open systems, this allows more systematic transportation and processing of different signer-related claims.

The design supports 2 flavours

• credentials can be embedded in the protected header, as presented below
• credentials can be referenced (id or URL + digest) in the protected header, and transported in the unsigned part of the signature

Please ignore the kid and other header properties as I took one of the ETSI examples that were made for an x509 case.

{
  "alg": "RS256",
  "cty": "json",
  "kid": "MFwwVqRUMFIxFTATBgNVBAMMDHNoYTMtZ29vZC1jYTEZMBcGA1UECgwQTm93aW5hIFNvbHV0aW9uczERMA8GA1UECwwIUEtJLVRFU1QxCzAJBgNVBAYTAkxVAgIETA==",
  "x5t#S256": "pCd-RteScUAe11slmKgUD2fXbJhqodCDLT4GgMSGTok",
  "x5c": [
    "MIID6zCCAtOgAwIBAgICBEwwDQYJYIZIAWUDBAMOBQAwUjEVMBMGA1UEAwwMc2hhMy1nb29kLWNhMRkwFwYDVQQKDBBOb3dpbmEgU29sdXRpb25zMREwDwYDVQQLDAhQS0ktVEVTVDELMAkGA1UEBhMCTFUwHhcNMTkwNzI5MDYxMTE4WhcNMjEwNTI5MDYxMTE4WjBUMRcwFQYDVQQDDA5zaGEzLWdvb2QtdXNlcjEZMBcGA1UECgwQTm93aW5hIFNvbHV0aW9uczERMA8GA1UECwwIUEtJLVRFU1QxCzAJBgNVBAYTAkxVMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzMWqwPhIzTPDwvG/5eHGY3/yTCdwPeAD7cOv92dLWF9V4piTDnLXczBLQpe5FxqurKVNIaHt7D4jKydDS3h1aj2A8eWMt+Zn/Mw5MgFx55D+6PrOcwNC74+QoRioJMC/C0KQv5YvtHSM7nuBtd8xfeI5p7FmaV8YsJt1ddNpi7FGJHRYXqo66HfNI/CzTcUqaA86Ra7TZ8GuagNuvYZnbaR1CLm4sYWDHVky9MH2L4p8u+I2mAT3pXZ5V+0XQdl8AJ3Y0LwTLsvFmx2jCIW9gCw7/7AtEPgcPVZpojTzgqEiU9l79G2jcSD7rjNZmayYH/KyeQ2OTy6eVscM0bkKXQIDAQABo4HIMIHFMA4GA1UdDwEB/wQEAwIGQDCBkwYIKwYBBQUHAQEEgYYwgYMwPgYIKwYBBQUHMAGGMmh0dHA6Ly9kc3Mubm93aW5hLmx1L3BraS1mYWN0b3J5L29jc3Avc2hhMy1nb29kLWNhMEEGCCsGAQUFBzAChjVodHRwOi8vZHNzLm5vd2luYS5sdS9wa2ktZmFjdG9yeS9jcnQvc2hhMy1nb29kLWNhLmNydDAdBgNVHQ4EFgQUPWGNOm0nzveLNETizrtUomSTmhYwDQYJYIZIAWUDBAMOBQADggEBAABUnlvonsB3i/LwVRQl4KxTguABxLgODcWnTt9z+ylTfFvg5neU+IeKn+cSQZx1jZ0CqOJleEb/osDJZK/PvsTsNH4OT64CcaP11TK1/YgxZ8t6J08jl+9rw6PKfT/IKaotBsN4BgCiNHtHn95ahPwRWTcwXOBkZkElX8bdKVKeKccxRsB6jrQJj1xYVn9B2aVhyLgcTZvmmhQWTYsy3SMbl3awOl0Ps0/9O/7Nr8dt+wyNKQiRwPGr89Ei07PfgANTEXKlk8xAmVCIIwzG4sB3cXf2f+3+1SPDO08OrCyrqJ9v2TPTiaMSaFlm5o1TY33zP2zmJUDhvD5GlWPOoPY="
  ],
  "typ": "jose+json",
  "sigT": "2020-07-14T13:03:42Z",
  "crit": ["sigT", "srAts"],
  "srAts": {
    "signedAssertions": [
      {
        "mediaType": "application/entity-statement+jwt",
        "encoding": "",
        "qVals": ["{signed entity statement 1 as JWT}", "{signed entity statement e as JWT}", "..."
        ]
      },
      {
        "mediaType": "application/wallet-attestation+jwt",
        "encoding": "",
        "qVals": ["signed Wallet attestation"]
      },
      {
        "mediaType": "application/verifier-attestation+jwt",
        "encoding": "",
        "qVals": ["signed verifier attestation"]
      },
      {
        "mediaType": "application/vc+ld+json+jose",
        "encoding": "",
        "qVals": ["Signed Entity Verifiable Credenial as JWS"]
      },
      {
        "mediaType": "application/vc+ld+json+jose",
        "encoding": "",
        "qVals": ["Signed Verifiable Key Attestation as JWS"]
      }
    ]
  }
}

As you know, smooth tracks make for an easy ride

[Michael Jones]

Alen, you wrote:

the only change for OIDC Fed is going from trust_chain → srAts.SignedAssertions → qVal object

However, the Trust Chain is the core data structure of OpenID Connect Federation. Alen, could you instead suggest a representation of srAts.SignedAssertions and/or qVal object within the Trust Chain, rather than suggesting replacing it?

‌

[Alen Horvat]

Hi Mike.

Yes, this is also an option. Signer attributes can be seen as trust marks (issued by 3rd party issuers (even from different federations)). This would also be a nice feature for OIDCFed. I discussed this with Giuseppe some time ago. In this case, the simplest approach would be to enable the trust mark to be a similar object as qVal. IMO this would be very interesting for some projects.

However, projects not using OIDCFed, would then use srAts. Hence we end up in the same situation we have today. Then OID4VP will use “jwt” header property etc, etc.

All this is great and nice. I saw an opportunity where the same structure could convey a wide range of information. Of course, use cases/frameworks will have to define profiles, what they accept/understand/… It’s not a magic box where you can put anything and expect everyone will understand and process the content :)

Note that the trust chain, as is, can be transported inside of the signer attributes. Maybe I used the wrong type above when I put "application/entity-statement+jwt"

There are pros/cons to both approaches. Either it is very specific and for every information new claim is introduced, or is generic and with it more verbose.

[Michael Jones]

We discussed this on the 21-Sep-23 working group call. Additional reviews are requested.

[Giuseppe De Marco]

@Alen Horvat does srAts support referenced objects?

In a way that a JWT may have its x5c and/or federation trust_chain in a top level and a srAts may describe these by giving a reference to a claim contained within the same JWT? (this avoid external http requests …)

as you shown I read x5c by its own, and I assume that trust_chain is the same, may a stAts reference it without copy/changing its content?
Anyway, at the same time, nothing prevents the definition of a new classification of a federation trust chain withing a stAts but this may increase the implementation delta between different products/solution

I’d go for the first approach

[Giuseppe De Marco]

We have discussed this during the editor’s call on 6 october 2023, we think that this issue brings a lot of interesting stuffs that we really appreciated, however we propose to close this issue and move this discussion on a brand new implementation profile, because we can’t handle an important change like the one proposed in this issue for the current status of the specs

[Giuseppe De Marco]

As discussed with Alen this proposal has sense and should be developed in some specific implementation profiles and not directly in this specs since it should not introduce features like this at the current stage