Re: [SPICE] Deliverables, implementability, formats

[Orie Steele <[e-mail]>]

Thanks for your comments.

Inline:

On Fri, Jan 19, 2024 at 6:20 PM Watson Ladd <[e-mail]> wrote:

> Dear flavoring enthusiasts,
>
> I'm writing in response to the charter text, and must confess to not
> having read all of the enormous flow of emails over the past few days
> as comprehensively as they deserved. I am concerned that the
> distinction between SPICE and the other related working groups (only
> one of which I know much about!) is based around largely irrelevant
> distinctions, that our deliverables are too far from an actual
> interoperable specification, and that there's a gap between the
> architecture doc and our deliverables that opens the question of where
> the work to fill them will be. I'll expound in reverse order, but
> these points do overlap somewhat.
>
> First the architecture doc discusses issuance and presentation, as
> well as extensibility points for key discovery and choices of formats.
>

I am not sure which document you are referring to... none of the drafts I
have published to the data tracker were meant to be a "starting point for
an architecture that the working group might adopt".

The drafts were meant to take the shortest path possible to explaining how
complex and evolving this space is.


> This strikes me as very ambitious, and we're only promising to deliver
> metadata discovery (something i am very dubious about) and selective
> disclosure.


If we can't do well with small tasks, I fear we should not attempt to
charter for larger ones.


> Who exactly is going to be responsible for the issuance
> protocol, the presentation protocol for other sorts of formats, the
> key discovery, and picking between JSON and CBOR (something that I
> don't understand why it matters so much: aren't they supposed to be
> the same semantically, or did we decide to nest representations inside
> for crypto reasons...)? These strike me as things any real world
> deployment needs to answer and we need to really nail down to have
> interoperability.
>
>
Indeed, the current text is attempting to reflect that the real world is
making progress on these topics.

Consider this recent PR:

-
https://github.com/WICG/identity-credential/pull/54/files#diff-5b2d57c713fadded2b8c7cbe949eb3d61b937b059a483ac29e6c85966cf03cf0R68

Interfaces we see developing in the wild are accounting for the format
indecision, so if we want to be compatible, we need to align with what they
are doing.

Just to be extra clear, browser and web apis (like OIDC) are not choosing
to only support CBOR or JSON, they are being built assuming both are
required to support use cases, perhaps CBOR will be more popular for some
use cases, and JSON will be more popular for others.

Secondly privacy preserving disclosure has to be paired with issuance
> to be useful, and there has to be a way to integrate it with other
> protocols securely.


Agreed, I expect this would end up being addressed in the details of a
given cryptographic system and serialization format.

PrivacyPass covers this well in their architecture document.


> I think we should say something about this, or
> that we're going to do something about it. There aren't terribly
> generic solutions, and something about what we're doing here (is it
> for the web? assuming a secure channel? what sort of binding and
> anti-replay do we need?) should be said.


Said in the charter? Can you propose some text?

I feel that this would need to be said in deliverables, if the deliverable
claims to address the design goals.


> Metadata discovery scares me:
> it implies that we don't have agreement on formats, protocols, etc.
>

I think we can say conclusively at this point that we (the people of the
internet) don't have agreement on this.

Note that x509, JOSE, COSE and PrivacyPass all exist.

and we're just going to have a bunch of separated islands with their
> own product ecosystem in each.


Yes, this is true today.


> I'm also skeptical given the temporal
> aspects that this works: i think you are stuck with a bunch of
> credentials you handed out earlier, or devices or software that was
> rolled out.


Interesting, typically credentials "expire" or are "revoked", and
renewal does offer an opportunity for new cryptography or new
serializations.

You might imagine being handed back a COSE credential where you had
previously had a JOSE one.


> I'd prefer to see actual interoperability and some
> thinking about what parts should be avoided because they involve
> policy.


You said "Policy", and I interpret this as "Issuer and Verifier" policies,
which apply to both "proof formats" and "claim formats".

We did create a draft starting to provide some guidance on this topic:

https://datatracker.ietf.org/doc/draft-steele-spice-profiles-bcp/



> It's also the case I think that issuers and verifiers have a
> much tighter connection than might be anticipated because the verifier
> needs to accept that the issuer can talk about the facts and is doing
> its job in issuance. I'm not sure how useful the generality is here.
>
>
I don't understand your last comment here.


> Thirdly I'm not sure about the relation to ongoing OAUTH work (which
> I've got concerns about): is it just they do JSON and we do CBOR? that
> seems pretty odd: can we just pick one?


I think I have addressed this above.


> Are we going to have parity,
> or if we're focusing on a different set of usecases can we discuss
> that explicitly in the charter?


Can you say what you wish to see? We have discussed this in some depth, and
it's usually boiled down to 2 world views:

1. digital credentials are for natural persons, and there are no use cases
for "legal entity credentials"... this seems pretty conclusively disputed
by GS1 ... https://ref.gs1.org/gs1/vc/ ... and GLEIF ...
https://www.gleif.org/en/vlei/introducing-the-verifiable-lei-vlei

2. digital credentials can have claims that are tuned to an industry use
case, and industries might prefer JSON to CBOR today, and might change in
the future... for example places where JWT was used in the past, might use
CWT in the future... again this approach seems validated by EAT:
https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat-25#name-eat-as-a-framework


> I feel like there's a bunch of common
> understanding among the group that isn't reflected here, which would
> be helpful to record so that we understand and people bringing new
> work understand what we are and aren't going to do.
>

Can you propose some text that you would like to see in the charter? or
deliverables you think that are needed to address this?


>
> Sincerely,
> Watson Ladd
>
> --
> Astra mortemque praestare gradatim
>
> --
> SPICE mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spice
>


-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>