Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add missing IANA registrations #144

Merged
merged 9 commits into from
Dec 21, 2023
175 changes: 160 additions & 15 deletions openid-4-verifiable-credential-issuance-1_0.md
Original file line number Diff line number Diff line change
Expand Up @@ -1300,7 +1300,7 @@ The Wallet is supposed to detect signs of fraudulent behavior related to the Cre

If an adversary is able to get hold of a key proof defined in (#proof_types), the adversary could get a Credential issued that is bound to a key pair controlled by the victim.

Note: For the attacker to be able to present to the Verifier a Credential bound to a replayed Key Proof, the attacker also needs to obtain the victim's private key. To limit this, servers are RECOMMENDED to check how the Wallet protects the private keys, using mechanisms such as Key Based Client Authentication defined in [@I-D.looker-oauth-attestation-based-client-auth].
Note: For the attacker to be able to present to the Verifier a Credential bound to a replayed Key Proof, the attacker also needs to obtain the victim's private key. To limit this, servers are RECOMMENDED to check how the Wallet protects the private keys, using mechanisms such as Key Based Client Authentication defined in [@!I-D.ietf-oauth-attestation-based-client-auth].

`nonce` parameter is the primary countermeasure against key proof replay. To further narrow down the attack vector, the Credential Issuer SHOULD bind a unique `nonce` parameter to the respective Access Token.

Expand Down Expand Up @@ -1434,9 +1434,12 @@ TBD
<organization>Microsoft</organization>
</author>
<author fullname="Michael B. Jones">
<organization>Microsoft</organization>
<organization>Self-Issued Consulting</organization>
</author>
<author initials="T." surname="Lodderstedt" fullname="Torsten Lodderstedt">
<organization>sprind.org</organization>
</author>
<date day="1" month="January" year="2023"/>
<date day="28" month="November" year="2023"/>
</front>
</reference>

Expand Down Expand Up @@ -1570,21 +1573,18 @@ TBD
<front>
<title>OpenID for Verifiable Presentations</title>
<author initials="O." surname="Terbu" fullname="Oliver Terbu">
<organization>ConsenSys Mesh</organization>
<organization>Mattr</organization>
</author>
<author initials="T." surname="Lodderstedt" fullname="Torsten Lodderstedt">
<organization>yes.com</organization>
<organization>sprind.org</organization>
</author>
<author initials="K." surname="Yasuda" fullname="Kristina Yasuda">
<organization>Microsoft</organization>
</author>
<author initials="A." surname="Lemmon" fullname="Adam Lemmon">
<organization>Convergence.tech</organization>
</author>
<author initials="T." surname="Looker" fullname="Tobias Looker">
<organization>Mattr</organization>
</author>
<date day="20" month="June" year="2022"/>
<date day="29" month="November" year="2022"/>
</front>
</reference>

Expand Down Expand Up @@ -1625,31 +1625,176 @@ TBD
<author fullname="Vladimir Dzhuvinov">
<organization>Connect2id</organization>
</author>
<date day="8" month="November" year="2023"/>
<date day="4" month="December" year="2023"/>
</front>
</reference>

<reference anchor="IANA.OAuth.Parameters" target="https://www.iana.org/assignments/oauth-parameters">
<front>
<title>OAuth Parameters</title>
<author>
<organization>IANA</organization>
</author>
<date/>
</front>
</reference>

<reference anchor="IANA.MediaTypes" target="https://www.iana.org/assignments/media-types">
<front>
<title>Media Types</title>
<author>
<organization>IANA</organization>
</author>
<date/>
</front>
</reference>

# IANA Considerations

## Sub-Namespace Registration

This section registers the value "urn:ietf:params:oauth:grant-type:pre-authorized_code" in the IANA "OAuth URI" registry established by "An IETF URN Sub-Namespace for OAuth" [@!RFC6755].
This specification registers the following URN in the IANA "OAuth URI" registry [@!IANA.OAuth.Parameters] established by [@!RFC6755].

* URN: urn:ietf:params:oauth:grant-type:pre-authorized_code
* Common Name: Pre-Authorized Code
* Change Controller: AB/Connect Working Group - openid-specs-ab@lists.openid.net
* Specification Document: (#token_request) of this document
* Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net
* Reference: (#token_request) of this spedification

## OAuth Parameters Registry
Sakurann marked this conversation as resolved.
Show resolved Hide resolved

This specification registers the following parameter names in the IANA "OAuth Parameters" registry [@!IANA.OAuth.Parameters] established by [@!RFC6749].

Sakurann marked this conversation as resolved.
Show resolved Hide resolved
* Parameter Name: wallet_issuer
* Parameter Usage Location: authorization request
* Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net
* Reference: (#credential-authz-request) of this specification

* Parameter Name: user_hint
* Parameter Usage Location: authorization request
* Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net
* Reference: (#credential-authz-request) of this specification

* Parameter Name: issuer_state
* Parameter Usage Location: authorization request
* Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net
* Reference: (#credential-authz-request) of this specification

Sakurann marked this conversation as resolved.
Show resolved Hide resolved
* Parameter Name: pre-authorized_code
* Parameter Usage Location: token request
* Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net
* Reference: (#token_request) of this specification

* Parameter Name: tx_code
* Parameter Usage Location: token request
* Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net
* Reference: (#token_request) of this specification

* Parameter Name: c_nonce
* Parameter Usage Location: token response
* Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net
* Reference: (#token-response) of this specification

* Parameter Name: c_nonce_expires_in
* Parameter Usage Location: token response
* Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net
* Reference: (#token-response) of this specification
Comment on lines +1692 to +1700
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would prefer to see these removed (a la #39) but I recognize this is in vain and am just putting something here for posterity.


## OAuth Dynamic Client Registration Metadata Registry

This specification registers the following client metadata name in the IANA "OAuth Dynamic Client Registration Metadata" registry [@!IANA.OAuth.Parameters] established by [@!RFC7591].

* Client Metadata Name: credential_offer_endpoint
* Client Metadata Description: Credential Offer Endpoint
* Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net
* Reference: (#credential_offer_endpoint) of this specification
Sakurann marked this conversation as resolved.
Show resolved Hide resolved

## OAuth Extensions Error Registry

This specification registers the following error values in the IANA "OAuth Extensions Error Registry" [@!IANA.OAuth.Parameters] established by [@!RFC6749].

* Name: invalid_credential_request
* Usage Location: resource access error response
* Protocol Extension: OpenID for Verifiable Credentials Issuance
* Change controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net
* Reference: (#credential-request-errors) of this specification

* Name: unsupported_credential_type
* Usage Location: resource access error response
* Protocol Extension: OpenID for Verifiable Credentials Issuance
* Change controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net
* Reference: (#credential-request-errors) of this specification

* Name: unsupported_credential_format
* Usage Location: resource access error response
* Protocol Extension: OpenID for Verifiable Credentials Issuance
* Change controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net
* Reference: (#credential-request-errors) of this specification

* Name: invalid_proof
* Usage Location: resource access error response
* Protocol Extension: OpenID for Verifiable Credentials Issuance
* Change controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net
* Reference: (#credential-request-errors) of this specification

* Name: invalid_encryption_parameters
* Usage Location: resource access error response
* Protocol Extension: OpenID for Verifiable Credentials Issuance
* Change controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net
* Reference: (#credential-request-errors) of this specification
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are not OAuth errors and therefore don't need to be registered and shouldn't be. see https://datatracker.ietf.org/doc/html/rfc6749#section-7.2

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are errors defined by a profile of OAuth. Other errors defined by other OAuth profiles are registered. For instance, https://openid.net/specs/openid-connect-core-1_0.html#ErrorContents registered errors defined by the OAuth profile called OpenID Connect. You can see their registrations at https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#extensions-error.

These errors defined by the OAuth profile called OpenID for Verifiable Credential Issuance also should and need to be registered.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are errors defined by a profile of OAuth. Other errors defined by other OAuth profiles are registered. For instance, https://openid.net/specs/openid-connect-core-1_0.html#ErrorContents registered errors defined by the OAuth profile called OpenID Connect. You can see their registrations at https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#extensions-error.

Yes but all of those registered OpenID Connect errors are returned from the authorization endpoint using the standard parameter for such. Registration for those makes sense and is one of those prescribed by https://datatracker.ietf.org/doc/html/rfc6749#section-8.5 (note that general protected resource application errors are not).

These errors defined by the OAuth profile called OpenID for Verifiable Credential Issuance also should and need to be registered.

These are errors for the Credential Request endpoint, which is an OAuth protected resource but is not an OAuth endpoint. The only protected resource errors that need registration are "for error values to be shared among OAuth token authentication schemes" (such as Bearer / DPoP) for when a "resource access request fails" https://datatracker.ietf.org/doc/html/rfc6749#section-7.2

The registry is not for general application layer errors from the protected resource.

selfissued marked this conversation as resolved.
Show resolved Hide resolved

## Well-Known URI Registry

This specification registers the well-known URI defined in (#credential-issuer-wellknown) in the IANA Well-Known URI registry defined in RFC 5785 [@!RFC5785].
This specification registers the following well-known URI in the IANA "Well-Known URI" registry established by [@!RFC5785].

* URI suffix: openid-credential-issuer
* Change controller: AB/Connect Working Group - openid-specs-ab@lists.openid.net
* Change controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net
* Specification document: (#credential-issuer-wellknown) of this document
* Related information: (none)

## Media Types Registry

This specification registers the following media types in the IANA "Media Types" registry [@!IANA.MediaTypes] in the manner described in [@!RFC6838].

* Type name: `application`
* Subtype name: `openid4vci-proof+jwt`
* Required parameters: n/a
* Optional parameters: n/a
* Encoding considerations: Uses JWS Compact Serialization, as specified in [@!RFC7515].
* Security considerations: See the Security Considerations in [@!RFC7519].
* Interoperability considerations: n/a
* Published specification: (#jwt-proof-type) of this specification
* Applications that use this media type: Applications that issue and store verifiable credentials
* Additional information:
- Magic number(s): n/a
- File extension(s): n/a
- Macintosh file type code(s): n/a
* Person & email address to contact for further information: Torsten Lodderstedt, torsten@lodderstedt.net
* Intended usage: COMMON
* Restrictions on usage: none
* Author: Torsten Lodderstedt, torsten@lodderstedt.net
* Change controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net
* Provisional registration? No

* Type name: `application`
* Subtype name: `openid4vci-proof+cwt`
* Required parameters: n/a
* Optional parameters: n/a
* Encoding considerations: Binary CBOR, as specified in [@!RFC9052]
* Security considerations: See the Security Considerations in [@!RFC8392].
* Interoperability considerations: n/a
* Published specification: (#cwt-proof-type) of this specification
* Applications that use this media type: Applications that issue and store verifiable credentials
* Additional information:
- Magic number(s): n/a
- File extension(s): n/a
- Macintosh file type code(s): n/a
* Person & email address to contact for further information: Torsten Lodderstedt, torsten@lodderstedt.net
* Intended usage: COMMON
* Restrictions on usage: none
* Author: Torsten Lodderstedt, torsten@lodderstedt.net
* Change controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net
* Provisional registration? No

# Acknowledgements {#Acknowledgements}

We would like to thank Paul Bastian, Vittorio Bertocci, Christian Bormann, John Bradley, Brian Campbell, Gabe Cohen, David Chadwick, Andrii Deinega, Giuseppe De Marco, Mark Dobrinic, Daniel Fett, Pedro Felix, George Fletcher, Timo Glasta, Mark Haine, Fabian Hauck, Roland Hedberg, Joseph Heenan, Alen Horvat, Andrew Hughes, Jacob Ideskog, Edmund Jay, Michael B. Jones, Tom Jones, Judith Kahrer, Takahiko Kawasaki, Niels Klomp, Ronald Koenig, Markus Kreusch, Adam Lemmon, Daniel McGrogan, Jeremie Miller, Kenichi Nakamura, Rolson Quadras, Nat Sakimura, Oliver Terbu, Arjen van Veen, David Waite, Jacob Ward for their valuable feedback and contributions to this specification.
Expand Down