Re: [SPICE] BoF: Problem Statements

[Orie Steele <[e-mail]>]

Thanks Henk, I agree with your improvements.

To me they boil down to the need for IETF to address the concept of "data
model" and "exchange mechanisms" for digital credentials, particularly ones
that rely on other IETF documents.

Tackling these problems will help achieve compliance and
certification goals, especially in complex domains like physical and
software supply chains, where we see a mix of technologies providing
overlapping and non overlapping functionality.

It would be nice to understand how WIMSE fits into this picture.

Regards,

OS


On Wed, Sep 13, 2023 at 9:51 AM Henk Birkholz <
[e-mail]> wrote:

> 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>
> >
> >
>


-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>