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

[Michael Prorock <[e-mail]>]

Orie. I couldn't agree more.

Thanks for getting this in place where hopefully we can move forward with
it.

Mike Prorock
CTO - mesur.io

On Fri, Dec 15, 2023, 07:37 Orie Steele <[e-mail]> wrote:

> 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>
> --
> SPICE mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spice
>