I support making the above changes to the charter.
OS
On Tue, Feb 20, 2024 at 6:59 PM <nada...@prodigy.net
<mailto:nada...@prodigy.net>> wrote:
Orie, many thanks for the dump on metadata, I understand now the
motive.____
If we keep it simple and just say a metadata Discover proposal for
specific technologies there can be different proposals or the WG can
make the call on which one is the one that they want to work on. We
can also have an OUT OF SCOPE section and specifically say that
general key discovery is out of scope. I don’t think this is too
much work as everything does not have to be done at once.____
* A standard Metadata Discovery protocol for JWT,CWT,
SD-JWT,SD-CWT,CWP and JWP technologies.____
__ __
* Out of Scope____
o General Key discovery is out of scope for this document,
there are several mechanisms for distributing or discovering
key material (references go here),____
__ __
*From:*Orie Steele <orie@transmute.industries>
*Sent:* Tuesday, February 20, 2024 10:18 AM
*To:* nada...@prodigy.net <mailto:nada...@prodigy.net>
*Cc:* Roman Danyliw <r...@cert.org <mailto:r...@cert.org>>; oauth
<oauth@ietf.org <mailto:oauth@ietf.org>>
*Subject:* Re: [OAUTH-WG] FW: Call for consensus on SPICE charter____
__ __
Thank you for making this so clear, and easy to review.
I'd like to unpack some of the intention behind the "metadata
discovery" deliverable, and hopefully this commentary will help
others chime in, on if it should be cut from scope.
The original intention was to generalize this capability from the
OAuth draft, to work with formats other than SD-JWT, what follows
are excerpts from
https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/
<https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/>:
> This specification defines the JWT Issuer Metadata to retrieve
the JWT Issuer Metadata configuration of the JWT Issuer of the JWT.
The JWT Issuer is identified by the iss claim in the JWT. Use of the
JWT Issuer Metadata is OPTIONAL.
> JWT Issuers publishing JWT Issuer Metadata MUST make a JWT Issuer
Metadata configuration available at the path formed by concatenating
the string /.well-known/jwt-issuer to the iss claim value in the
JWT. The iss MUST be a case-sensitive URL using the HTTPS scheme
that contains scheme, host and, optionally, port number and path
components, but no query or fragment components.
> A JWT Issuer Metadata configuration MUST be queried using an HTTP
GET request at the path defined in Section 4.
> The following is a non-normative example of a HTTP request for
the JWT Issuer Metadata configuration when iss is set to
https://example.com <https://example.com>:
> GET /.well-known/jwt-issuer HTTP/1.1
> Host: example.com <http://example.com>
> If the iss value contains a path component, any terminating /
MUST be removed before inserting /.well-known/ and the well-known
URI suffix between the host component and the path component.
> The following is a non-normative example of a HTTP request for
the JWT Issuer Metadata configuration when iss is set to
https://example.com/user/1234 <https://example.com/user/1234>:
> GET /.well-known/jwt-issuer/user/1234 HTTP/1.1
> Host: example.com <http://example.com>
> A successful response MUST use the 200 OK HTTP and return the JWT
Issuer Metadata configuration using the application/json content type.
> An error response uses the applicable HTTP status code value.
"""
{
"issuer":"https://example.com <https://example.com>",
"jwks":{
"keys":[
{
"kid":"doc-signer-05-25-2022",
"e":"AQAB",
"n":"nj3YJwsLUFl...5z50wMuzifQrMI9bQ",
"kty":"RSA"
}
]
}
}
"""
The problem I see with removing a general purpose deliverable for
this, is that we will see this kind of "key discovery stuff"
repeated over and over again, as it is in SD-JWT-VC, possibly with
minor or major differences that impact interoperability, and make it
difficult for an issuer to upgrade from supporting SD-JWT to SD-CWT
or CWP or go the other direction (there are good reasons the believe
a vendor might want to support multiple credential formats).
My preference would be to define this "metadata discovery thing" in
one place, and then refer to it like this in digital credential
documents:
"Key discovery is out of scope for this document, there are several
mechanisms for distributing or discovering key material, see $ref1,
$ref2, etc."
Other documents might take a different approach:
$ref is mandatory to support, other mechanisms for distributing or
discovering key material are optional, see $ref2, etc...
As you may be aware, DIDs are a mechanism for distributing key
material, but for which resolution is not concretely defined, this
has caused them to be very difficult to use, and it produced formal
objects to their publication in W3C.
https://lists.w3.org/Archives/Public/public-new-work/2021Sep/0000.html
<https://lists.w3.org/Archives/Public/public-new-work/2021Sep/0000.html>
OIDC also supports discovering issuer key material, through well
known endpoints.
Moving key material discovery out of scope for IETF deliverables is
often a reasonable approach, but it is problematic if it is done for
CWTs and JWTs differently.
The objective of the "metadata discovery document" was to ensure
that SD-CWT and SD-CWP could reference a document that did what
SD-JWT-VC is doing, without repeating the text that it currently
includes.
It might even be possible for SD-JWT-VC to share that metadata
discovery document as a normative reference, and then
interoperability and reuse could be achieved across JWT,CWT,
SD-JWT,SD-CWT,CWP and JWP digital credential profiles.
However, if this feels like biting off too much for a new working
group charter, I would not be opposed to defering it to a potential
rechartering discussion, its possible OAUTH, or WIMSE will have
solved the problem for the formats above by then anyway.
Regards,
OS
____
__ __
On Tue, Feb 20, 2024 at 10:32 AM <nada...@prodigy.net
<mailto:nada...@prodigy.net>> wrote:____
Introduction____
Digital credentials are essential to identity, authorization,
licenses, certificates, and digitization use cases that are part
of modernization efforts targeting efficiency and transparency.____
A digital credential expresses claims or attributes about a
subject, such as their name or age, and their cryptographic
keys. Some sets of claim names have already been defined by the
IETF and other standards development groups (e.g., OpenID
Foundation).____
Digital credentials typically involve at least three entities
but can include more:____
* An "issuer", an entity (person, device, organization, or
software agent) that constructs and secures digital
credentials.____
* A "holder", an entity (person, device, organization, or
software agent) that controls the disclosure of credentials.____
* A "verifier", an entity (person, device, organization, or
software agent) that verifies and validates secured digital
credentials.____
In some contexts, holders may be willing either to partially
disclose some values of their attributes or to demonstrate some
properties about their attributes without disclosing their
values. When disclosed by an entity, a proof of the digital
credential needs to be provided and verified, so that only the
legitimate holder of the digital credential can take advantage
of its possession.____
Some holders may wish to carry more than one digital credential.
These credentials, together with associated key material, can be
stored in an identity digital wallet.____
The W3C has published the 'Verifiable Credentials Data Model
v2.0' specification (VCDM) with data serialization in JSON-LD.
In this charter, the VCDM defined concept of “verifiable
credential” and “verifiable presentation” is captured using the
wording "digital credential" and "digital presentation"
respectively.____
Goal____
The SPICE WG will profile existing IETF technologies and address
residual gaps that would enable their use in digital credentials
and presentations based upon JWT and CWT technologies.____
* The JOSE WG is already standardizing a token format for
unlinkability & selective disclosure in the form of JWP/CWP
(draft-ietf-jose-json-web-proof
<https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-proof/>). The SPICE
WG will profile these token formats for use with digital credentials.____
* The OAUTH WG is already standardizing a token format for
unlinkability & selective disclosure in the form of
SD-JWT/SD-JWT-VC (draft-ietf-oauth-selective-disclosure-jwt
<https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/> and
draft-ietf-oauth-sd-jwt-vc
<https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/>). The SPICE WG will
define SD-CWT/SD-CWT-VC, analogs for these JWT-based tokens but based on CWT.____
The SPICE WG will coordinate with the RATS, OAuth, JOSE, COSE
and SCITT working groups that develop architecture, patterns and
definition documents related to the identity and credential
space. The SPICE WG will build on cryptographic primitives
defined in the CFRG (e.g., BBS Signatures) and will not define
novel cryptographic schemes.____
The SPICE WG will not develop digital credentials for any
particular use case. The SPICE WG will create general-purpose
profiles which will enable credential issuers, holders and
verifiers to easily build on existing IETF CWT and JWT
technologies.____
Program of Work____
The SPICE WG is expected to develop:____
* An informational Architecture that defines the terminology
(e.g., Issuer, Holder,Verifier, Claims, Credentials,
Presentations) and the essential communication patterns
between roles, such as credential issuance, where an issuer
delivers a credential to a holder, and presentation, where a
holder delivers a presentation to a verifier.____
* Proposed standard documents for digital credential profiles
covering JWP and CWP (from JOSE) that enable digital
credentials with unlinkability and selective disclosure.
This work will include registering claims that are in the
JWT and CWT registries to enable digital credentials to
transition from one security format to another (i.e.,
JSON/CBOR).____
* A proposed standard document defining SD-CWT, a profile of
CWT inspired by SD-JWT (from OAuth) that enables digital
credentials with unlinkability and selective disclosure.____
* A proposed standard Metadata Discovery protocol using
HTTPS/CoAP for CBOR-based digital credentials to enable the
3 roles (issuers, holders and verifiers) to discover
supported protocols and formats for keys, claims, credential
types and proofs. The design will be inspired by the OAuth
"vc-jwt-issuer" metadata work (draft-ietf-oauth-sd-jwt-vc
<https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/>)
which supports ecosystems using JSON serialization.____
Milestones____
* 04-2025 - Submit an informational Architecture document to
the IESG for publication____
* 10-2025 - Submit a proposed standard document covering a
JWP/CWP profile for digital credentials to the IESG for
publication____
* 10-2025 - Submit a proposed standard document defining
SD-CWT to the IESG for publication____
* 03-2026 - Submit a document as a proposed standard covering
Metadata Discovery to the IESG for publication____
Introduction
<https://datatracker.ietf.org/doc/charter-ietf-spice/00-00/#introduction>____
Goal
<https://datatracker.ietf.org/doc/charter-ietf-spice/00-00/#goal>____
Program of Work
<https://datatracker.ietf.org/doc/charter-ietf-spice/00-00/#program-of-work>____
Milestones
<https://datatracker.ietf.org/doc/charter-ietf-spice/00-00/#milestones>____
____
____
____
____
*From:*Orie Steele <orie@transmute.industries
<mailto:orie@transmute.industries>>
*Sent:* Monday, February 19, 2024 6:15 PM
*To:* Anthony Nadalin <nada...@prodigy.net
<mailto:nada...@prodigy.net>>
*Cc:* Roman Danyliw <r...@cert.org <mailto:r...@cert.org>>; oauth
<oauth@ietf.org <mailto:oauth@ietf.org>>
*Subject:* Re: [OAUTH-WG] FW: Call for consensus on SPICE
charter____
____
Inline:____
On Mon, Feb 19, 2024, 7:34 PM <nada...@prodigy.net
<mailto:nada...@prodigy.net>> wrote:____
Orie, thanks for the response____
____
I’m still confused on this charter proposal as I read this
charter it is to create architecture, patterns and
definitions for electronic credentials. The charter should
be free of any technology including W3C, if people want
clarity about what an electronic credential is then they can
help out with the definitions since that is an output, so I
don’t agree with how W3C is mentioned in the charter. ____
____
As you pointed out below, W3C has defined credentials that are
simply public keys bound to an origin (used as authenticators),
and issuer signed claims about a subject (like JWTs)____
____
So far the people who have been most active seem interested in
generalizing the "signed public key and attributes" version of a
digital credential. That definition lines up well with JWT and
CWT with the cnf claim, and mDoc (as I understand it).____
____
Most of the value W3C VC Data Model provides is focused on
creating a structure for the claims that go in the credential.
The security of W3C VCs based on JWT, SD-JWT, and COSE comes
from the IETF drafts not from W3C.____
____
Some of the protocol connection points also come from IETF
documents, for example aud, nonce and cnf.____
____
Most of the value JWT and CWT provide, is through the public
claims and private claims in the associated IANA registries. For
example, this is where the cnf claim that ties proof of
possession to credentials is registered.____
____
It's my understanding that mdocs have a namespace approach to
claims as well.____
____
Creating conventions for claims in a credential format is
profiling. iso mdoc is a profile of COSE Sign1 in that sense.____
____
You can consider the W3C documents that rely on JWT, CWT and
COSE as profiles of those IETF standards. Instead of using JWT
or CWT claimsets, the W3C uses JSON-LD.____
____
A major reason for spice forming was to explore alternative
claims structures, and to align CWT and JWT conventions for
credentials that DO NOT require JSON-LD.____
____
The way I read the charter is that interested parties will
work on various profiles to map/profile various technologies
to the create architecture, patterns and definitions
documents, this will be done with various members that
submit drafts.____
____
Relative to WebAuthn what is produced is a credential, its
not a JWT or SD-JWT but as the charter reads that is not the
only credentials under consideration, if this is the case
then the charter severely lacks clarity on what is the goal.____
____
I don't think there is utility in IETF creating a profile for
webauthn based credentials, because they are not meant to be
presented beyond the origin they are bound to.____
____
____
ISO is just another standards org, W3C, OIDF, OASIS, etc
work with ISO with no issues, I assume profile will be
created by various members that submit drafts, if no one is
interested in mDL/ISO then that’s fine.____
____
I still think this charter needs more clarity as I point out____
____
Can you suggest text?____
____
____
*From:*Orie Steele <orie@transmute.industries
<mailto:orie@transmute.industries>>
*Sent:* Friday, February 16, 2024 10:11 AM
*To:* nada...@prodigy.net <mailto:nada...@prodigy.net>
*Cc:* Roman Danyliw <r...@cert.org <mailto:r...@cert.org>>;
oauth <oauth@ietf.org <mailto:oauth@ietf.org>>
*Subject:* Re: [OAUTH-WG] FW: Call for consensus on SPICE
charter____
____
Hey Tony,____
____
On Thu, Feb 15, 2024 at 1:36 PM <nada...@prodigy.net
<mailto:nada...@prodigy.net>> wrote:____
1) Do you support the charter text? Or do you have
objections or blocking concerns (please describe what
they might be and how you would propose addressing the
concern)?
Not sure I support at this point, I understand the need
for an architecture document with patterns and
definitions, etc.
There is a lot of work going on outside the IETF in this
area such as the mDL work in ISO that already has
patterns and definitions along with credential formats
(mdoc) and transports (ble/http/nfc). I don’t believe
the IETF should ignore these efforts since most of the
driving licence and passport communities/companies are
adopting this as one of the standards that issuers and
verifiers will use. The same is true for W3C WebAuthn.____
WebAuthN cannot produce standard digital signatures, and so
it cannot be used to produce standard digital credentials
(for example it cannot be used to produce JWT or SD-JWT).
It could produce authentications for public keys that could
be bound to credentials, but because of the origin binding
in WebAuthN, this would not fit well with the "audience"
typically used for digital credentials (usually there is no
audience)
You might find this thread on possible relation between mDoc
and CWT interesting:
https://mailarchive.ietf.org/arch/msg/spice/xiRpmd-Bexv94qentlGg1Snjw1A/
<https://mailarchive.ietf.org/arch/msg/spice/xiRpmd-Bexv94qentlGg1Snjw1A/>____
The architecture, patterns and definitions should be
free from technology, I don't know why W3C is mentioned
in the introduction as the only technology, this should
not be in the introduction but along with other
technologies such as mDL/mdoc, webauthn, etc when
describing profiles. As the goal would be for interested
parties to produce profiles of other technologies to fit
the architecture document with patterns and definitions.____
W3C is mentioned because some W3C members asked for a term
other than "Verifiable Credentials" to be used... and they
asserted the "Verifiable Credentials" implies the JSON-LD
data model developed in W3C.
ISO was not emphasized because formal coordination would
require contribution from ISO experts, and we have had
relatively low engagement from them.
____
I believe that the WG if formed should also think about
holder verification and patterns and attestations that
can be used.____
____
Interesting. I think this is covered under the metadata
discovery deliverable, but if you feel it could be made more
clear, please send text.____
____
Also there needs to be a notion of a "reader/wallet/etc"
that can potentially store credentials (not necessarily
the user or verifier) and release/store credentials upon
"user" consent.____
This sounds like an application to me.
How do you see this related to "credential formats" or
"issuer/holder/verifier metadata"?
____
There are other models than the 3 party that VCs use, so
these also need to be considered in the architecture,
patterns and definitions documents to enable profiles
for other technologies.____
Agreed, OAuth JWTs/SD-JWTs, and ISO mDocs are examples we
have discussed.
Are there others you would like to see considered? ____
I believe in the 1st 3 items in Goals but I don't
believe it would be in the best interest to define a
metatdata protocol, as this sounds like this would be a
protocol for obtaining DID documents, there are already
many protocols out there for metadata retrieval, not
sure there is a need for another one, if one is needed
for DIDs then that may be better done in W3C as this
does not seem to fit well with the charter____
Discovering attestations for wallets seems to fit here, why
should URLs or URNs (DIDs) be specifically marked as out of
scope?
For consideration, JWK / COSE Key Thumbprints are good
alternatives to DIDs which have been standardized / are
being standardized in the IETF:
-
https://datatracker.ietf.org/doc/draft-ietf-cose-key-thumbprint/
<https://datatracker.ietf.org/doc/draft-ietf-cose-key-thumbprint/>
____
This charter seems to be very scoped to W3C technology,
I understand that interested parties will have to
contribute if they want to have other technologies
included but the charter in general does not seem to
allow this, so removing specific technology will allow
this to happen.____
____
We chose to use "Digital Credential" and "Digital
Presentation" specifically to keep the door open to CWT and
COSE Sign1 structures which are used in IETF and ISO.
____
I would be happy to give provide specific text changes
to the charter.____
I think it would be great if you could offer text that
refines your comment about format support, and holder/wallet
metadata / attestations.
____
2) If you do support the charter text:
3) Are you willing to author or participate in the
developed of the WG drafts?
yes
• Are you willing to review the WG drafts?
yes
• Are you interested in implementing the WG drafts?
I'm willing to see how we can use these outputs with the
other industry technologies.____
Thank you for your comments.
____
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>____
____
____
-- ____
____
*ORIE STEELE
*Chief Technology Officer
www.transmute.industries <http://www.transmute.industries>____
<https://transmute.industries/>____
____
__ __
-- ____
__ __
*ORIE STEELE
*Chief Technology Officer
www.transmute.industries <http://www.transmute.industries>____
<https://transmute.industries/>____
--
ORIE STEELE
Chief Technology Officer
www.transmute.industries
<https://transmute.industries>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
