Re: [SPICE] BoF: Problem Statements

[Henk Birkholz <[e-mail]>]

Hi Orie,
hi list!

I tried to map your problem statements (which I like in a ton, in 
principle! but they could be more problem'esque) to my individual 
understanding of spice.

As a result, I went kinda off-trail and wrote my version of the problem 
statements. Not sure, if that is of help, but what I felt was a bit 
absent were the different dimension of the spice work - of which I think 
the most important ones are probably: credential-type data 
models/encodings, activities performed with respect to credentials, and 
the bigger picture how to re-combine data model specific activities 
across data models.

Here's the result. Please bash. It's a very early pass.


0. Businesses lack a consistent way to create and present credentials. 
For example, there is no coherent interoperability between credential 
solutions based on X.509, CWT, and JWT with respect to the typical 
activities related to them, such as certification, transparency, or 
presentation. Each of these activities deviate slightly from each other 
depending on the credential format/data model used.

1. Other credentials that exist or are emerging today, such as Digital 
Drivers Licenses, Vaxination QR codes, or Verifable Credentials as a 
whole do not come with all the acitvities illustrated in (0.) and also 
lack uniform handling, correspondingly. For example, credential 
formats/data model often don't come with consistent credential delivery 
or presentation protocols.

2. There is no guided procedure enabling the transformation of 
credentials from one format/data model to another. For example, 
presenting a digital drivers license using one format & data model to 
obtain the classes of vehicles that operation of is permitted in another 
format & data model

3. There is no architectural documentation about which types of 
activities apply to all or some of the credential format/data models 
that exist or are emerging. Similarly, there is no rules set defined 
that businesses can use to nest methods related to different credential 
data models, e.g., protecting arbitrary content along with registered 
claim names in CWT or JWT. Or presenting an ISO mDoc with OAuth or via mTLS.

How does this work? It is far from perfect, but does it get the scope 
across? Maybe I went beyond intended scope.


Viele Grüße,

Henk

On 08.09.23 01:04, Orie Steele wrote:
> Hello Fremen (dune reference... sorry).
> 
> As we continue to try to find the relationships between SPICE, OAUTH, 
> COSE, JOSE, WIMSE etc...
> 
> I am sharing some problem statements and solutions to help us refine our 
> BoF request... Please help bash them.
> 
> 0. Businesses need a consistent set of building blocks for securing 
> artifacts and enabling certification, transparency and presentation of 
> credentials to preserve privacy and confidentiality, and reduce friction 
> and improve automation and compliance.
> 
> 1. Digital wallets need a consistent vocabulary and terminology that can 
> be leveraged to build 3 party model protocols, where the trust can 
> travel with the data, instead of just in the channels that move the data.
> 
> 2. Credential exchange protocols need to support high volume business to 
> business communications, in addition to user consent oriented OAuth / 
> OpenID Connect based flows.
> 
> These boil down to fresh looks at some topics that have been previously 
> explored with IETF.
> 
> OAuth helped define how to identify issuers (iss), subjects (sub), and 
> verifiers (aud)... JOSE and JWT have a set of data model building blocks 
> that work well for JSON based information models, and many of the same 
> conventions have been ported to COSE for use with CWT / CBOR.
> 
> OAuth also addressed some details around delivering tokens from 
> "issuers" to "clients".... In the latest OAuth documents, we see 
> "wallets" show up as clients, and the audience binding gives way to the 
> 3 party model, where a credential with key binding can be presented or 
> partially disclosed to verifiers that the original credential issuer may 
> never have imagined.
> 
> There have been various recent IETF drafts that focused on "shapes" of 
> credentials, for example 
> https://datatracker.ietf.org/doc/draft-ietf-rats-eat/ 
> <https://datatracker.ietf.org/doc/draft-ietf-rats-eat/> and 
> https://openid.net/specs/openid-connect-userinfo-vc-1_0-00.html 
> <https://openid.net/specs/openid-connect-userinfo-vc-1_0-00.html> and 
> https://datatracker.ietf.org/doc/draft-looker-oauth-jwt-cwt-status-list/ 
> <https://datatracker.ietf.org/doc/draft-looker-oauth-jwt-cwt-status-list/> and https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/ <https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/>
> 
> The JSON based information models are built on JWT / SD-JWT
> The CBOR based information models are built on CWT. (maybe SD-CWT in the 
> future).
> 
> There are other expressions of digital credentials, particularly ISO 
> mDOC and W3C Verifiable Credentials, but they don't build on IETF standards.
> 
> It was before my time at IETF, but I have heard stories about attribute 
> certificates and urn's that seem to be earlier ancestors of these 
> current technology standards.
> 
> The challenges are not new.
> 
> How to express claims in ways that verifiers can understand?
> 
> How to exchange credentials, how to discover verification or encryption 
> keys, what transports and protocols to use?
> 
> How can we leverage the expertise of IETF to address these challenges, 
> without reinventing wheels unless there is an opportunity to make a 
> worthy improvement?
> 
> Can SPICE be a home to credential data modeling concerns for both the 
> JOSE and COSE communities?
> 
> What parts of OAuth and OIDC are working well for credential exchange, 
> and what is the best way to handle the scenarios that require more 
> automation and higher volume?
> 
> How can we improve our problem statement and solution description and 
> refine what we have in 
> https://datatracker.ietf.org/doc/bofreq-prorock-secure-patterns-for-internet-credentials-spice/ <https://datatracker.ietf.org/doc/bofreq-prorock-secure-patterns-for-internet-credentials-spice/> today?
> 
> Regards,
> 
> OS
> 
> 
> -- 
> 
> 
> ORIE STEELE
> Chief Technology Officer
> www.transmute.industries
> 
> <https://transmute.industries>
> 
>