Re: [SPICE] [OAUTH-WG] SPICE will not support JSON, JWT or SD-JWT

[Orie Steele <[e-mail]>]

Denis,

I didn't comment on your initial email, since we have discussed much of
this on the SPICE calls,
and I believe you know my position on all these points, but since you asked
for a response on the list,
I am providing one inline:

On Fri, Dec 8, 2023 at 10:57 AM Denis <[e-mail]> wrote:

> + 1 to Justin
>
>
>
>
> *Let us start with what I agree with. What I agree with in the proposed
> charter: *
> "The SPICE WG will develop a framework in support of the 'Three Role
> Model', selective disclosure, and unlinkability".
>
> One participant from the OAuth mailing list mentioned that the
> unlinkability property between verifiers was out of the scope of SD-JWT.
> However, it is possible to adapt the mechanism described in SD-JWT to
> support the unlinkability property between verifiers when using batches of
> one-time-use credentials.
> Such an approach would provide a smooth transition to support the unlinkability
> between verifiers while specifying another mechanism able to support the
> unlinkability
> between verifiers while using a single credential.
>
> That's all that I agree with.
>
>
>
>
>
> * Let us continue with what I disagree with. What I disagree with in the
> introduction section: *
> 1) "Digital credentials based on IETF standards have use cases ranging
> from personal credentials, such as drivers licenses and vaccination proofs,
>      to business-to-business or business-to-government applications;"
>
> Add:  "Consumer-to-Business, Consumer-to-Government* , ..."*
>
> "One example is fraud and counterfeiting prevention in cross-border trade
> documents by protecting digital representations of mill test reports,
> bills of materials, bills of lading, or commercial invoices".
>
> These examples are not appropriate since they involve the use of
> electronic signatures or of electronic seals. Please remove this sentence.
>
>
As we've discussed several times, our use case is general purpose
digital credentials, not credentials exclusively for natural persons owning
a smartphone.

>
> 2) "These scenarios were addressed with registered claim names in JOSE and
> COSE, but resulting solution have lead to fragmented approaches,
> where each working group rediscovers the essential architecture and
> conventions necessary for issuers to make claims about subjects".
>
> "registered claim names" while useful cannot address all business needs.
> Claim names not registered by IANA need to be considered and supported.
>
>
This is true of JOSE and COSE today, there is a section reserved for
private use, and private claim names.
This is one of the few places where the charter attempts to narrow scope,
and it seems unlikely that you will convince the group to widen here.

>
> 3) "The SPICE WG focuses on a few explicit higher level objectives:
>
>   (a) unreliability enabling trustworthy exposition of minimal required
> information to prevent correlation and other attacks,
>   (b) selective disclosure enabling controlled exposition and an
> authorized subset of linkability,
>   (c) a well-curated, concise claim vocabulary enabling cross-domain
> interchangeability via registration authorizes (i.e., IANA)."
>
> (a) the item (a) is not understandable: "unreliability"?
> (b) "selective disclosure" is fine, however, the remaining of the sentence
> is not understandable.
> (c) See above: Claim names not registered by IANA also need to be
> considered and supported.
>
>
Thanks, I've refined that sentence here:
https://github.com/transmute-industries/ietf-spice-charter/pull/16

>
> 4) "These objectives can be achieved by leveraging industry adopted
> standards and managing trade-offs between cutting-edge and well-established
> cryptography".
>
> The wording " by leveraging industry adopted standards and" should be
> removed, since this would prevent creativity.
>
>
I disagree, we have been asked to narrow scope and opening things up here,
such as working with new formats, or inventing new formats, would be a
mistake in my opinion.

As an example, we could reinvent all of JOSE and COSE in Protocol Buffers,
should our charter allow us to do that?

>
> 5) "As a guiding principle for the SPICE WG, claims that work well in JSON
> must work well in CBOR, without loss of semantics.
>     Compact expressions of claims consume less resources and expose less
> attack surface, these properties are in support sustainable design".
>
> As already said, claim names not registered by IANA also need to be
> considered and supported. In order to consume less resources for
> transferring data,
> the use of template or schemas able to make references to other templates
> or schemas should be considered. Template or formats are essential
> for interoperability and to facilitate the encoding of the data as well as
> the automatic validation of received data. Template or formats can
> constraint
> an element to be an object, array, string, number, boolean, or null or
> constraint an element to be a member of a set of values.
>
>
I'm interested in registered claim names for "template" / "schema" / "data
definition" links.

We don't need to register every private claim, if we have a way to
understand them, that is well known and understood.

For JSON, that might mean registering `@context` for JSON-LD, `schema` for
JSON Schema, etc... but that's the kind of detail that does not belong in
the charter.

>
> 6) "The SPICE WG will support digital credential formats leveraging
> existing IETF standards and IANA registries,  "
>
> Considering only "*existing IETF standards*" would prevent to address new
> technologies.
> As already said, claim names not registered by IANA also need to be
> considered and supported.
>
> I disagree.

>
> 7) "Digital credentials are identity documents with attributes (public or
> private claims in IANA registries) about the identity".
>
> As already said, claim names not registered by IANA also need to be
> considered and supported.
>
>
I disagree.

>
> 8) "The identifiers referenced could be about any subject, but common
> examples include people, devices, assets, organizations and processes".
>
> Only individuals should be considered. When individuals are considered,
> primary requirements come from a privacy perspective (collection
> limitation, user consent;, etc)
> Devices, assets, organizations and processes should be out of the scope.
>
> I disagree.

>
> 9) "*Examples of producing and consuming digital credentials with the
> "Three Role Model" include credential endorsement by third parties,*
> credential trustworthiness
>      via remote attestation evidence appraisal for issuers, or credential
> transparency via notarization".
>
> "credential trustworthiness via remote attestation evidence appraisal for
> issuers" is not understandable,
> "or credential transparency via notarization". Since the communication
> between an Holder and a Verifier is a direct, there is no need for
> notarization.
>
>
>
I disagree, this sentence is related to well known concepts such as
identity proofing, and requirements that an issuer might have on a digital
wallet before provisioning a credential, see:

https://pages.nist.gov/800-63-FAQ/


> *What I disagree with in the in-scope section*
>
> 10) "The work of the SPICE WG aligns JWT and CWT registered claim names
> ..."
>
> As already said, claim names not registered by IANA also need to be
> considered and supported.
>
> I disagree.

>
> 11) "The framework will provide an architecture that enables consistent
> application of JOSE and COSE,  "
>
> JOSE and COSE are mostly used for the transfer of data that contain an array,
> a string, a number or a boolean associated with a claim name.
> However, a credential "template" should first be advertised by an Issuer
> to both Verifiers and Holders. JOSE or COSE formats are not adequate for
> that purpose.
>
> When using BBS+, data objects transmitted between an Holder and a Verifier
> will be HEX encoded and, in addition to an header, will contain indexes
> and values (usually up to 32 bytes). Claim names, whether they are
> registered or not by IANA, are of no use at that stage. JOSE or COSE may or
> may not be
> adequate for the transfer. The argument raised later on, i.e. "Compact
> encoding matters and aligning JSON and CBOR provides the basis for simpler
> interoperability
> and smaller specification" is not necessarily valid.
>
>
BBS is in scope, to the extent that it is supported by JOSE and COSE....
it's currently in a draft format, but I believe it's possible to start
building on... W3C is already trying to build on top of it.

The approach taken there is to turn application/vc+ld+json into
application/n-quads (an expensive operation on untrusted data), and then
use the nquads to produce the message set input to BBS.

We've tested this approach and it has scaling issues, we'd like to see a
simpler approach adopted for digital credentials.

>
>
> *What I disagree with in the out-of-scope section *
> 12)  "The working group will NOT address transport protocols, such as
> those developed at OAUTH, OIDF, W3C or ISO in the scope of its initial
> charter."
>
> There is a need to support a credential request protocol different from
> the one specified by ODIF. It should be based on the use of credential
> templates or schemas.
> It should allow the individual to select which set of claim names and/or
> values should be incorporated. It should also be efficient when issuing or
> renewing batches
> of one-time-use credentials. Generally speaking, the working group should
> either define or reference the protocols that will need to be used.
>
> The reason this sentence is there, is that folks wanted to be able to use
SPICE formatted digital credentials in other protocols... it also helps us
narrow scope.
Widening scope here will make the charter less achievable in my opinion.

>
> 13)   "The working group will NOT address specific credential use cases,
> such as "personal credentials ... "
>
> I wonder what is meant by using the wording " personal credentials".
> Credentials issued to human beings should be the single use case to
> consider.
>
> Vertical specific use cases are out of scope. This is an area where we
could narrow further... we could focus only on credentials for humans,
dogs, or products...

Based on the conversations we've had, there does not seem to be strong
consensus to narrow scope to a single vertical.

>
> 14)  "The SPICE WG's work items will not require nor forbid the use of
> JSON-LD".
>
> Such a sentence will not help to achieve interoperability, since
> credential "templates" should be advertised by an Issuer to both Verifiers
> and Holders.
>
>
This sentence is critical to distinguishing SPICE Digital Credential
formats from W3C Verifiable Credential formats, it was requested by W3C
Members.

The goal is for SPICE to be less opinionated about application layer media
types (json-ld is the only supported claims format),
and more opinionated about security (sign and verify operations are not
trivial to exploit, when input data is not carefully validated against
known schemas).

As I pointed out earlier, this sentence does not preclude using SPICE to
secure JSON-LD or JSON Schema... it just doesn't force us, in our
charter... to all support the same schema language.

The W3C VCWG charter also did not force that group to only do JSON-LD, but
that ended up being what the working group consensus reflected,
and part of that consensus was to do none JSON-LD work in other places,
such as ISO, IETF or ... other places... that's part of why we are having
this discussion here.

Based on our experience working with digital credentials, we don't believe
that forcing people to learn a schema language to issue, present and verify
is a path to success.

We also believe, based on our experience working in this space, that
forcing implementers to copy syntax that they don't understand, and telling
them they don't need to understand it, is misleading and harmful.

Since you seem to disagree with me frequently on this point,
I encourage you to apply for invited expert status to the W3C VCWG,
I am sure you will find many people there who strongly agree with you.

More candidly, much of what you wish to discuss continues to be
inappropriate for a charter document, but very appropriate for a working
group...

I hope we can continue these discussions in a working group with an
approved charter.


> *Other comments *
>
> The wording used in this proposed charter is only the tip of the iceberg.
> Other considerations are missing, such as:
>
> - how can the application used by the individual know which set of claims
> and/or *which kind of proofs *will be required by the Verifier
>    in order to allow the application to perform an action related to a
> specific purpose ?
>
> This sounds like a thing to discuss in a working group, assuming a charter
was accepted.

>
> - how can the user know that he can trust what is presented in the display
> and that his entries will not be intercepted by a rogue application ?
>
> This sounds like a thing to discuss in a working group, assuming a charter
was accepted.

>
> - how can the Verifier know that the application used by the individual is
> "appropriate", that the cryptographic keys are well protected and
> restricted
>   to be used only by that application ?
>
> This sounds like a thing to discuss in a working group, assuming a charter
was accepted.

>
> Denis
>
> Our company is interested in SPICE from the perspective that the N-party
> model is about independent entities that are all Issuers, Holders and
> Verifiers at times.
>
> To maximize usefulness and adoption, the "secure pattern(s)" should work
> for all types of entities, across all use cases, in highly heterogeneous
> environments, and throughout the life of each entity.
>
> If on a business trip, an employee of a rental car company lends me a
> digital key to unlock a specific car, there are 2 humans, 2 orgs, a car
> and, a door lock entity that are all expected to cryptographically enforce
> some verifiable business logic (likely attested software agents, that are
> entities themselves). The problem that needs solving is not about one
> credential, it's about enabling the long, complex, cryptographic
> chains/graphs that are necessary to make each credential truly useful.
>
> From that perspective, the north star is attack surface minimization. Our
> perspective is that SPICE should specify the minimalistic and most secure
> "how". The benefits of potential deviations should be evaluated against
> incremental attack surface and loss of interoperability.
>
> While this may not be how other WGs usually work, this WG works on behalf
> of the independent entities it intends to empower and secure.
>
> Manu
>
> On Fri, Dec 8, 2023 at 4:19 AM Warren Parad <wparad=
> [e-mail]> wrote:
>
>> I'm with Justin, I can't fathom why you would couple a WG to a format. We
>> know from building great software we should not constrain the *how* but
>> instead only the *what. *VC likely lives in SPICE, but that doesn't mean
>> anything about *how* such things should be implemented. Likewise, if
>> there is an OAuth-related need to extend to COSE or CBOR, I would expect
>> that the OAuth WG to pick it up, since it falls into the *What* of the
>> WG.
>>
>> Talking about spec formats doesn't make sense in any charter.
>>
>> - Warren
>>
>> On Fri, Dec 8, 2023 at 4:57 AM Justin Richer <[e-mail]> wrote:
>>
>> All of the VC-related elements that are currently in OAuth quite frankly
>>> do not belong there, but there’s not currently a better place to put them.
>>> SPICE would be just such a better place, if it gets chartered as a WG.
>>> Intentionally limiting SPICE to only COSE just in response to OAuth is
>>> shortsighted and will not result in the best work that this group of people
>>> can accomplish.
>>>
>>>  — Justin
>>>
>>> On Dec 7, 2023, at 4:50 PM, Orie Steele <[e-mail]>
>>> <[e-mail]> wrote:
>>>
>>> Hello,
>>>
>>> On the last SPICE proponents call, we discussed the follow up from the
>>> last IETF.
>>>
>>> OAuth has adopted "verifiable credentials" in JSON related work items,
>>> and unless something changes, we expect that trend to continue for JSON
>>> based claimsets,
>>> verifiable credential related extensions to OAuth defined data formats,
>>> like JWT, SD-JWT,
>>> Status Lists, VC-JWT-SD, and any future formats that might be used in
>>> access or identity tokens (BBS / JWP).
>>>
>>> On the SPICE calls we've seen no major interest in doing credential
>>> related work in JSON,
>>> while we have seen a lot of interest in doing digital credential work in
>>> CBOR.
>>>
>>> Now is your chance to argue that SPICE (in its first ever charter) can
>>> effectively support aligning JWT / CWT claimsets,
>>> and meaningfully address our intended charter deliverables, for which
>>> there is now an updated PR:
>>>
>>> https://github.com/transmute-industries/ietf-spice-charter/pull/15
>>>
>>> and that OAuth should not handle the JSON part of the "3 party model",
>>> "verifiable credentials" and "JSON related digital identity formats".
>>>
>>> Unless we receive a strong response contradicting the assertions in the
>>> subject of this email,
>>> we plan to reduce the scope of SPICE to focus on CBOR.
>>>
>>> If SPICE forms, and things change in OAuth, perhaps a future SPICE
>>> charter might attempt alignment.
>>>
>>> We will gather feedback for 4 weeks, to account for the holidays,
>>> after which we will revise the draft charter to put JSON, JWT, SD-JWT
>>> and associated claims work out of scope.
>>>
>>> Regards,
>>>
>>> OS
>>>
>>> --
>>>
>>> ORIE STEELE Chief Technology Officer www.transmute.industries
>>> <https://transmute.industries/>
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>> --
>>> SPICE mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/spice
>>>
>> --
>> SPICE mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/spice
>>
>
>
>

-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>