From b765c1e7d24ba19c1e42236b7ff67caaf658b0e2 Mon Sep 17 00:00:00 2001 From: peppelinux Date: Wed, 2 Aug 2023 17:52:06 +0200 Subject: [PATCH] chore: cleanup --- docs/en/relying-party-solution.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/en/relying-party-solution.rst b/docs/en/relying-party-solution.rst index 95a42817d..0b495f127 100644 --- a/docs/en/relying-party-solution.rst +++ b/docs/en/relying-party-solution.rst @@ -98,7 +98,7 @@ The payload of the QR Code is a **Base64 encoded string** based on the following eudiw://authorize?client_id=`$client_id`&request_uri=`$request_uri` -In the Same Device Flow the parameter **client_id** and **request_uri** are the same if the ones used in the Cross Device Flow with the only difference about the url schema and the removal of the Verifier's FQDN from the URL. +In the Same Device Flow the parameter **client_id** and **request_uri** are the same if the ones used in the Cross Device Flow with the only difference about the url schema and the removal of the Verifier's FQDN from the URL. In the Same Device Flow the Relying Party uses a HTTP response redirect (status code 302) to give to the Wallet Instance the resource where the request object is available for download, as represented in the following non-normative example: @@ -108,7 +108,7 @@ In the Same Device Flow the Relying Party uses a HTTP response redirect (status HTTP/1.1 /pre-authz-endpoint Found Location: eudiw://authorize? client_id=https%3A%2F%2Fverifier.example.org%2Fcb - &request_uri=https%3A%2F%2Fverifier.example.org%2Frequest_uri_endpoint%2Funique-session-identifier + &request_uri=https%3A%2F%2Fverifier.example.org%2Frequest_uri_endpoint .. note:: The Same Device flow proposed in this specification is under discussion and must be considered as experimental.