Re: [SPICE] BoF: Problem Statements

[Hesham ElBakoury <[e-mail]>]

Hi Henk,
I sent an email about using digital driver license to the identity-discuss
group which spurs good discussion that you may want to follow.

Thanks
Hesham

On Wed, Sep 13, 2023, 7:52 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>
> >
> >
>
> --
> SPICE mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spice
>