Skip to content

Commit

Permalink
Merge pull request #17 from peppelinux/mbj-metadata-references
Browse files Browse the repository at this point in the history 
@peppelinux agreed that we needed to make these changes before asking for public reviews of the next version of the spec.
  • Loading branch information
@selfissued
selfissued authored Aug 19, 2024
2 parents 331696e + c3c8352 commit 3c68113
Showing 1 changed file with 51 additions and 27 deletions.
78 changes: 51 additions & 27 deletions openid-federation-wallet-1_0.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -202,7 +202,7 @@ Web Wallet Native Application
Progressive Web Application Wallet (PWAW)
: PWAW is a web application that looks like a native app. It can be installed on a Personal Device and not necessarily using the operative system specific app-store. The advantage with a PWAW is that it gives the End-User the same experience as a Mobile Native Wallet Application while also offering the benefits of a web application. PWAW can be Custodial or Non-Custodial.

## Establishing Trust With The Holder
## Establishing Trust with the Holder

Since the Holder may not be an Organizational Entity and cannot be registered as an Organization through registration services, it is not represented within a Trust Chain and does not qualify as a Federation Entity. This context sets the stage for understanding the unique position of the Holder in relation to the Trust Chain and Federation Entities.

Expand Down Expand Up @@ -334,7 +334,7 @@ TBD: example 3 about problem solved with a Subordinate Statement trust_marks par

The process of trust establishment in federated environments is illustrated in this section through specific use cases involving Wallet Instances, Credential Issuers (CIs), and Credential Verifiers (CVs).

## Wallet Checking The Non-Revocation Of Its Wallet Provider
## Wallet Checking the Non-Revocation of its Wallet Provider

...

Expand Down Expand Up @@ -483,6 +483,30 @@ We would like to thank the following individuals for their comments, ideas, and
</front>
</reference>

<reference anchor="OpenID.Discovery" target="https://openid.net/specs/openid-connect-discovery-1_0.html">
<front>
<title>OpenID Connect Discovery 1.0</title>

<author fullname="Nat Sakimura" initials="N." surname="Sakimura">
<organization abbrev="NAT.Consulting (was at NRI)">NAT.Consulting</organization>
</author>

<author fullname="John Bradley" initials="J." surname="Bradley">
<organization abbrev="Yubico (was at Ping Identity)">Yubico</organization>
</author>

<author fullname="Michael B. Jones" initials="M.B." surname="Jones">
<organization abbrev="Self-Issued Consulting (was at Microsoft)">Self-Issued Consulting</organization>
</author>

<author fullname="Edmund Jay" initials="E." surname="Jay">
<organization abbrev="Illumila">Illumila</organization>
</author>

<date day="15" month="December" year="2023"/>
</front>
</reference>

<reference anchor="OpenID.Registration" target="https://openid.net/specs/openid-connect-registration-1_0.html">
<front>
<title>OpenID Connect Dynamic Client Registration 1.0</title>
Expand Down Expand Up @@ -635,15 +659,15 @@ are listed in the table below.
The table and examples below use metadata parameters defined by
[@!OpenID.Federation], [@!RFC8414], and [@!OpenID4VP].

| **Metadata Parameter** | **Status** | **Value** |
|----------|----------- | ------|
| jwks | REQUIRED | A JSON Web Key Set (JWKS) that represents the Wallet Provider's public keys. |
| authorization_endpoint | REQUIRED | Endpoint for obtaining the authorization for the issuance of the Wallet Attestation. |
| token_endpoint | REQUIRED | Endpoint for obtaining the Wallet Attestation. |
| aal_values_supported | OPTIONAL | List of supported values for the Authenticator Assurance Level, as defined in [ NIST Special Publication 800-63B](https://pages.nist.gov/800-63-3/sp800-63b.html#sec4). These values specify the security level of the app. Values are trust framework specific. |
| grant_types_supported | REQUIRED | The grant types supported by the token endpoint.|
| token_endpoint_auth_methods_supported | REQUIRED | Supported authentication methods for the token endpoint.|
| token_endpoint_auth_signing_alg_values_supported | REQUIRED | Supported signature algorithms for the token endpoint.|
| Metadata Parameter | Status | Description | Reference|
|----------|---------|---------------|---------|
| jwks | REQUIRED | A JSON Web Key Set (JWKS) that represents the Wallet Provider's public keys | Section 5.2.1 of [@!OpenID.Federation] and JWK [@!RFC7517] |
| authorization_endpoint | REQUIRED | Endpoint for obtaining the authorization for the issuance of the Wallet Attestation | Section 2 of [@!RFC8414] |
| token_endpoint | REQUIRED | Endpoint for obtaining the Wallet Attestation | Section 2 of [@!RFC8414] |
| aal_values_supported | OPTIONAL | List of supported values for the Authenticator Assurance Level, as defined in [ NIST Special Publication 800-63B](https://pages.nist.gov/800-63-3/sp800-63b.html#sec4). These values specify the security level of the app. Values are trust framework specific | this specification |
| grant_types_supported | REQUIRED | Grant types supported by the token endpoint | Section 2 of [@!RFC8414] |
| token_endpoint_auth_methods_supported | REQUIRED | Supported authentication methods for the token endpoint | Section 2 of [@!RFC8414] |
| token_endpoint_auth_signing_alg_values_supported | REQUIRED | Supported signature algorithms for the token endpoint | Section 2 of [@!RFC8414] |

Below is a non-normative example of `openid_wallet_provider` metadata:

Expand Down Expand Up @@ -684,15 +708,15 @@ OpenID Credential Issuers with the `openid_credential_issuer` Entity Type Identi
are listed in the table below.

The table and examples below use metadata parameters defined by
[@!OpenID.Federation], [@!RFC8414], and [@!OpenID4VCI].
[@!OpenID.Federation], [@!RFC8414]], [@!RFC9126], [@!OpenID.Discovery], and [@!OpenID4VCI].

The usage described below is intended to enable
the cryptographic material used for the Credential issuance operation be consistent
and verifiable using the Trust Chain.

| Metadata Parameter | Status | Description |
|------|----------|---------------------------------------------------------------------------------------------------------------------|
| jwks | REQUIRED | JSON Web Key Set directly embeds the public keys used by the Credential Issuer for its signature operations, such as signing Digital Credentials. |
| Metadata Parameter | Status | Description | Reference |
|----------|---------|---------------|---------|
| jwks | REQUIRED | JSON Web Key Set directly embeds the public keys used by the Credential Issuer for its signature operations, such as signing Digital Credentials | Section 5.2.1 of [@!OpenID.Federation] and JWK [@!RFC7517] |

Below is a non-normative example of a payload of an Credential Issuer Entity Configuration:

Expand Down Expand Up @@ -806,18 +830,18 @@ OpenID Wallet Credential Verifiers with the `openid_credential_verifier` Entity
are listed in the table below.

The table and examples below use metadata parameters defined by
[@!OpenID.Federation], [@!RFC7591] and [@!OpenID4VP].
[@!OpenID.Federation], [@!RFC7591], [@!OpenID.Registration], [@!OAuth.JARM], and [@!OpenID4VP].

| Metadata Parameter | Status | Description | Reference |
|----------------------------------------|------------------------------------------------------------------------------------------------------------|---------------|-----------|
| client_id | REQUIRED | It MUST contain an HTTPS URL that uniquely identifies the Credential Verifier. | [@!RFC7591], Section 3.2.1 and [@!OpenID.Registration], Section 3.2 |
| client_name | REQUIRED | Human-readable string name of the Credential Verifier used for representing the Credential Verifier to the User. | [@!RFC7591], Section 2 |
| request_uris | OPTIONAL | JSON Array of `request_uri` values that are pre-registered by the Credential Verifier. These URLs MUST use the https scheme. | [@!OpenID.Registration], Section 2 |
| response_uris_supported | OPTIONAL | JSON Array of response URI strings to which the Wallet Instance MUST send the Authorization Response using an HTTP POST request. | this specification |
| authorization_signed_response_alg | OPTIONAL | String identifying the JWS algorithm that MUST be used for signing authorization responses. The algorithm `none` MUST NOT be used. | [@!RFC7515] and [@!OAuth.JARM], Section 3 |
| vp_formats | OPTIONAL | JSON object defining the formats and proof types of Verifiable Presentations and Verifiable Credentials the Credential Verifier supports. | [@!OpenID4VC-HAIP], Section 7.2.7 and OpenID4VP, Section 9.1 |
| presentation_definitions_supported | OPTIONAL | JSON Array of supported presentation_definition objects that MUST be compliant to the syntax defined. | this specification, [@!DIF.PresentationExchange], Section 5 and [@!OpenID4VC-HAIP], Section 7.2.8 |
| jwks | REQUIRED | JSON Web Key Set document, passed by value, containing the protocol specific keys for the Credential Verifier. | [@!OAuth.JARM], Section 3, [@!OpenID.Federation], Section 5.2.1, and JWK [@!RFC7517] |
|----------|---------|---------------|---------|
| client_id | REQUIRED | It MUST contain an HTTPS URL that uniquely identifies the Credential Verifier | Section 3.2.1 of [@!RFC7591] and Section 3.2 of [@!OpenID.Registration] |
| client_name | REQUIRED | Human-readable string name of the Credential Verifier used for representing the Credential Verifier to the User | Section 2 of [@!RFC7591] |
| request_uris | OPTIONAL | JSON Array of `request_uri` values that are pre-registered by the Credential Verifier. These URLs MUST use the `https` scheme. | Section 2 of [@!OpenID.Registration] |
| response_uris_supported | OPTIONAL | JSON Array of `response_uri` strings, as specified by [@!OpenID4VP], to which the Wallet Instance MAY send the Authorization Response using an HTTP POST request | this specification |
| authorization_signed_response_alg | OPTIONAL | String identifying the JWS algorithm that MUST be used for signing authorization responses. The algorithm `none` MUST NOT be used. | [@!RFC7515] and Section 3 of [@!OAuth.JARM] |
| vp_formats | OPTIONAL | JSON object defining the formats and proof types of Verifiable Presentations and Verifiable Credentials the Credential Verifier supports | Section 7.2.7 of [@!OpenID4VC-HAIP] and Section 9.1 of [@!OpenID4VP] |
| presentation_definitions_supported | OPTIONAL | JSON Array of supported `presentation_definition` objects | this specification, Section 5 of [@!DIF.PresentationExchange], and Section 7.2.8 of [@!OpenID4VC-HAIP] |
| jwks | REQUIRED | JSON Web Key Set document, passed by value, containing the protocol specific keys for the Credential Verifier | Section 5.2.1 of [@!OpenID.Federation] and JWK [@!RFC7517] |

Below is a non-normative example of the payload of a Credential Verifier Entity Configuration:

Expand Down Expand Up @@ -946,7 +970,7 @@ Below is a non-normative example of the payload of a Credential Verifier Entity
}
````

### Security Considerations About The Parameters request_uris And response_uris_supported
### Security Considerations about the Parameters `request_uris` and `response_uris_supported`

There are scenarios where the Credential Verifier's endpoints are attested by a trusted third party, such as a registration service owned by a federation Intermediate. This Intermediate attests to the Credential Verifier's metadata and ensures its integrity and authenticity by utilizing `metadata` and the `metadata_policy` in the Subordinate Statement about that Credential Verifier, as defined in the OpenID Federation specification.

Expand All @@ -956,7 +980,7 @@ To enhance the security of implementations, it is generally recommended that Cre

For this reason, the parameters `metadata` or `metadata_policy` SHOULD fix the supported URIs to prevent wallet hijacks to fraudolent endpoints and at the same time allow URI randomization using fragments.

### Security Considerations About The End-User's Data Protection Using presentation_definitions_supported
### Security Considerations about the End-User's Data Protection Using `presentation_definitions_supported`

The `presentation_definitions_supported` enhance the End-User data protection within wallet trust frameworks. By defining the specific presentation definitions that a Credential Verifier is authorized to use, this parameter limits the amount of personal data that can be requested. This constraint prevents the over-asking of personal data, aligning with the principles of data minimization and purpose limitation under privacy regulations.

Expand Down

0 comments on commit 3c68113

Please sign in to comment.