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

fix: mistakes and ambiguities removed related to PE and scopes #157

Merged
merged 2 commits into from
Nov 6, 2023
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 6 additions & 14 deletions docs/en/relying-party-solution.rst
Original file line number Diff line number Diff line change
Expand Up @@ -188,17 +188,13 @@ To attest a high level of security, the Wallet Instance submits its Wallet Insta

Below the description of the parameters defined in *OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer (DPoP)*.

.. note::
The use of DPoP doesn't represent any breaking changes to Wallet Instances that do not support DPoP to a *request_uri* endpoint, since it is assumed to use it as an additional security mechanisms for the attestation of the status of the Wallet Instance.

If the DPoP HTTP Header is missing, the Relying Party would assume the lowest attestable level of security to the Wallet Instance it is interacting with.
If the DPoP HTTP Header is missing, the Relying Party would assume the lowest attestable level of security to the Wallet Instance it is interacting with.

DPoP HTTP Header
^^^^^^^^^^^^^^^^

A **DPoP proof** is included in the request using the HTTP Header ``DPoP`` and containing a JWS. The JWS MUST be verified with the public key made available in the Wallet Instance Attestation (``Authorization: DPoP``).


The JOSE header of the **DPoP JWS** MUST contain at least the following parameters:

.. list-table::
Expand Down Expand Up @@ -288,7 +284,7 @@ The Relying Party issues the signed Request Object, where a non-normative exampl
}
.
{
"scope": "eu.europa.ec.eudiw.pid.it.1 pid-sd-jwt:unique_id+given_name+family_name",
"scope": "eu.europa.ec.eudiw.pid.it.1 tax_id_number",
"client_id_scheme": "entity_id",
"client_id": "https://relying-party.example.org",
"response_mode": "direct_post.jwt",
Expand Down Expand Up @@ -353,11 +349,7 @@ The JWS payload parameters are described herein:

.. warning::

This implementation profile use the parameter ``scope`` within the request instead of the ``presentation_definition``.

Using the parameter ``scope`` requires that the Relying Party Metadata MUST
contain the ``presentation_definition``, where a non-normative example of it
is given below:
Using the parameter ``scope`` requires that the Relying Party Metadata MUST contain the ``presentation_definition``, where a non-normative example of it is given below:

.. code-block:: JSON

Expand All @@ -366,7 +358,7 @@ is given below:
"id": "presentation definitions",
"input_descriptors": [
{
"id": "pid-sd-jwt:unique_id+given_name+family_name",
"id": "eu.europa.ec.eudiw.pid.it.1",
"name": "Person Identification Data",
"purpose": "User authentication",
"format": "vc+sd-jwt",
Expand Down Expand Up @@ -432,7 +424,7 @@ Below is a non-normative example of the decrypted JSON ``response`` content:
"id": "04a98be3-7fb0-4cf5-af9a-31579c8b0e7d",
"descriptor_map": [
{
"id": "pid-sd-jwt:unique_id+given_name+family_name",
"id": "eu.europa.ec.eudiw.pid.it.1",
"path": "$.vp_token.verified_claims.claims._sd[0]",
"format": "vc+sd-jwt"
}
Expand Down Expand Up @@ -578,7 +570,7 @@ Below is a non-normative response example:
},
"presentation_definitions": [
{
"id": "pid-sd-jwt:unique_id+given_name+family_name",
"id": "eu.europa.ec.eudiw.pid.it.1",
"input_descriptors": [
{
"id": "sd-jwt",
Expand Down
Loading