Re: [SPICE] Call for consensus on SPICE charter

[Kristina Yasuda <[e-mail]>]

Thank you, Orie for the detailed response!

Happy to hear that there is an appetite and a room to explore/design extensibility points to bridge SD-CWT and mdocs. Would be happy to contribute.

Overall, the latest SPICE charter I have read looks good to me! Thank you for the work and explicitly mentioning SD-JWT and SD-JWT.

Cheers,
Kristina

From: Orie Steele <[e-mail]>
Sent: Friday, February 9, 2024 3:03 PM
To: Kristina Yasuda <[e-mail]>
Cc: [e-mail]
Subject: Re: [SPICE] Call for consensus on SPICE charter

Inline:

On Fri, Feb 9, 2024 at 4:09 PM Kristina Yasuda <[e-mail]<mailto:[e-mail]>> wrote:
Hi Orie,
Thank you. Guess my question was why can’t mdocs be used for the use-cases that SD-CWT is being designed for? And the answer seems to be “because one needs to purchase an ISO standard where mdoc is being defined”?

That's my answer at this point in time, but that doesn't mean it needs to be a working group's answer.

mdocs are not exactly CWTs, rather CBOR structure signed using COSE, but they already have a salt-hash based selective disclosure mechanism.

COSE Sign1 as defined in 9052 can be verified with certificates or public keys, and there are different protected header hints to make this easy.

A CWT is a COSE Sign1 that has a payload that is a CBOR map, where the labels in that map are defined in a registry.

My guess would be that ISO did not create such a requirement for mDoc, and the payload is something other than a CBOR map, or, if it is a CBOR map, that some of the cbor map keys might already have collisions with https://www.iana.org/assignments/cwt/cwt.xhtml

The collisions would be a problem, however we have a possible escape hatch.

https://datatracker.ietf.org/doc/draft-ietf-cose-cwt-claims-in-headers/

^ using this draft, you could have "SD-*" style disclosures to a protected header (assuming mDoc allows you to set protected headers), and you could leave the mDoc payload as is.

The current SD-CWT approach also uses the unprotected header of the cose-sign1... not sure if ISO mDoc allows that.

This is just guessing about how we might attempt to address this challenge.

As an aside, it's very nice that an unprotected header exists in COSE since we don't need to do the disclosure encodings with `~` like we do in SD-JWT.

As "SD-CWT" is a "CWT", whereas an SD-JWT, is a "JWT" with a "~".

If the WG formed and SD-CWT was adopted, ISO could be normatively referenced, and although it would make implementing from the IETF document alone impossible, we do occasionally see normative references to specifications that are behind paywalls, not just from ISO, but from IEEE, and ASTM, etc...

That said, I am generally not in favor of relying on paywalled specifications for security, I agree with what John wrote here:

https://mailarchive.ietf.org/arch/msg/cfrg/aHDFKTVRAKYsjdkW7yK6fmSh_2U/

mdocs also define issuer PKI to be x509 and holder key binding to be raw COSE key, which helps with interop but could be turned into an extensibility point.

Addressing details like these, is exactly why we feel the metadata document is essential.

Another draft which might be helpful for doing key binding with cose key is https://datatracker.ietf.org/doc/draft-ietf-cose-key-thumbprint/

Thinking a bit more about your comment... a new COSE key claim could be defined, and you could possibly use the cose-key format to pass along additional data, but I would be cautious blending media types like application/cose-key with custom extensions, that could lead to unpredictable polyglot formats.

For those not familiar, W3C has struggled with a similar challenge in Verifiable Credentials: https://tess.oconnor.cx/2023/09/polyglots-and-interoperability

I would be concerned that blending SD-CWT and mDoc together could end up destroying their unique value.

But it is an intriguing idea! I don't have enough visibility into mDoc to see exactly how it could work.

At a minimum I think it would be excellent to clearly define the edge between SD-CWT and mDoc, based on my limited understanding of mDoc, I think that boils down to a paywalled algorithm for disclosing commitments that an issuer has made to claims, in other words, the disclosure algorithm and its verification process are the only parts of mDoc, that are security oriented, that are not built on top of RFC9052... but again, I am guessing about a document I have not read.


Best,
Kristina


________________________________
From: Orie Steele <[e-mail]<mailto:[e-mail]>>
Sent: Friday, February 9, 2024 12:31:38 PM
To: Kristina Yasuda <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Re: [SPICE] Call for consensus on SPICE charter

Hey Kristina,

I'm not an mDoc expert so I expect you will be able to answer that question better than I can.

To save you the trouble of reading the "SD-CWT/SD-CWT-VC" draft (and there is an experimental implementation I developed based on OAuth's SD-JWT reference implementation".

"SD-CWT/SD-CWT-VC" basically just takes the OAuth SD-JWT approach and makes it work with CWT claimsets instead of JWT claimsets.

So where OAuth registers:

- https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-07#name-json-web-token-claims-regis

Spice would register similar properties in:

- https://www.iana.org/assignments/cwt/cwt.xhtml

You said: "Personally, I would like to see SD-CWT/SD-CWT-VC to be backwards compatible with mdocs, but that can be discussed once in the draft.

I don't know the content type of the ISO mDoc cose-sign1 payload, is it a CBOR map? Could it be a CWT claimset? If the answer to both of those is yes, I see a possibility to align, but there could be lots of other challenges.

Having not read the ISO spec in question, I can't answer more than that.

Thanks for your comment about the W3C VC Data Model v2, I filed an issue to track it here:

https://github.com/transmute-industries/ietf-spice-charter/issues/29

Feel free to pile on any additional changes you would like to see there.

OS


On Fri, Feb 9, 2024 at 2:22 PM Kristina Yasuda <Kristina.Yasuda=[e-mail]<mailto:[e-mail]>> wrote:
Hi,

What is the relationship between SD-CWT/SD-CWT-VC and mdocs defined in ISO/IEC 18013-5?
At least, mdocs should be mentioned in the charter.
Personally, I would like to see SD-CWT/SD-CWT-VC to be backwards compatible with mdocs, but that can be discussed once in the draft.

small nits in the charter text:
VCDM 2.0 has not yet been published, so the last paragraph in the Introduction should be rephrased.
Best,
Kristina
--
SPICE mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/spice


--



ORIE STEELE
Chief Technology Officer
www.transmute.industries<http://www.transmute.industries/>

[https://ci3.googleusercontent.com/mail-sig/AIorK4xqtkj5psM1dDeDes_mjSsF3ylbEa5EMEQmnz3602cucAIhjLaHod-eVJq0E28BwrivrNSBMBc]<https://transmute.industries/>


--



ORIE STEELE
Chief Technology Officer
www.transmute.industries<http://www.transmute.industries/>

[https://ci3.googleusercontent.com/mail-sig/AIorK4xqtkj5psM1dDeDes_mjSsF3ylbEa5EMEQmnz3602cucAIhjLaHod-eVJq0E28BwrivrNSBMBc]<https://transmute.industries/>