Re: [SPICE] Call for consensus on SPICE charter

[Orie Steele <[e-mail]>]

Inline:

On Fri, Feb 9, 2024 at 4:09 PM Kristina Yasuda <
[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]>
> *Sent:* Friday, February 9, 2024 12:31:38 PM
> *To:* Kristina Yasuda <[e-mail]>
> *Cc:* [e-mail] <[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]> 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]
> https://www.ietf.org/mailman/listinfo/spice
>
>
>
> --
>
>
> ORIE STEELE
> Chief Technology Officer
> www.transmute.industries
>
> <https://transmute.industries/>
>


-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>