Skip to content

Commit

Permalink
feat(arf) Renumber footnotes eu-digital-identity-wallet#140
Browse files Browse the repository at this point in the history
  • Loading branch information
@skounis
skounis committed Apr 25, 2024
1 parent 39740e6 commit 2360dea
Showing 1 changed file with 20 additions and 20 deletions.
40 changes: 20 additions & 20 deletions docs/arf.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -1120,7 +1120,7 @@ To be done.

#### 6.2.2 EUDI Wallet Instance activation

##### 6.2.2.1 Required trust relationships[^15]
##### 6.2.2.1 Required trust relationships[^14]

After its' installation, a new EUDI Wallet Instance will need to be
activated by the Wallet Provider. Activation has at least the following
Expand Down Expand Up @@ -1441,7 +1441,7 @@ Regarding the technical implementation of these steps:
* The mechanism for step 3 is described in section 6.3.4.

##### 6.3.2.4 Relying Party trusts device binding
The Relying Party SHALL be able to trust that an attestation it receives was not copied and replayed. In other words, the Relying Party trusts that the attestation is bound to the same device to which the Provider issued it [^16].
The Relying Party SHALL be able to trust that an attestation it receives was not copied and replayed. In other words, the Relying Party trusts that the attestation is bound to the same device to which the Provider issued it [^15].

The Relying Party can trust that this is the case if the EUDI Wallet Instance signs some contextual information with the private key of the attestation. This information SHALL include a random number generated by the Relying Party. To verify this signature, the Relying Party needs to receive the public key of the attestation, which SHALL be signed (directly or indirectly) by the Provider of the attestation. By signing the public key, the Provider certifies that the public key indeed belongs to the attestation. The Relying Party SHALL additionally verify that the Wallet Instance is in possession of the corresponding private key; the Relying Party does so by verifying the signature over the random number generated by the Relying Party.

Expand All @@ -1468,7 +1468,7 @@ The mechanism(s) for User binding depend on the type of use case:
transaction, on behalf of the Relying Party. If User binding is
required in such cases, the Relying Party can request the User
portrait, next to other attributes, and the EUDI Wallet Instance can
release it. The portrait SHALL be signed by a trusted Provider [^17].
release it. The portrait SHALL be signed by a trusted Provider [^16].
The human supervisor then visually compares this portrait to the face
of the person presenting the attestation. However, please note that the
presence and use of the User portrait in the PID will be further
Expand All @@ -1483,7 +1483,7 @@ The mechanism(s) for User binding depend on the type of use case:
User portrait for user authentication by the Relying Party is generally
considered to be impractical. Relying Parties SHALL therefore trust
User authentication mechanisms present on or connected to the device
which the EUDI Wallet Instance is installed on [^18].
which the EUDI Wallet Instance is installed on [^17].


##### 6.3.2.6 User trusts the identity of the Relying Party
Expand Down Expand Up @@ -1541,7 +1541,7 @@ of such a document and has a cryptographic proof of its authenticity with
a validity period that is typically short, for example - several weeks.

This implies that an attestation Provider will renew the attestation
regularly during the validity period of the document[^19]. Also, an
regularly during the validity period of the document[^18]. Also, an
attestation Provider MAY issue multiple attestations that are
simultaneously valid but represent the same document. For example, a User
MAY have a mobile passport on their private phone and their work phone.
Expand Down Expand Up @@ -1596,7 +1596,7 @@ invalidate an attestation. For example, in many jurisdictions the police
are allowed to confiscate a driving license if the User is caught is a
serious traffic violation. Another example is an electronic prescription
for medicines that is valid only once and must not be usable anymore
after the User has received the medicines[^20] . A third example is when
after the User has received the medicines[^19] . A third example is when
the attestation Provider and the Authentic Source for that attestation
are different parties. If so, the Authentic Source contains the
authoritative information about whether an attribute value must be
Expand Down Expand Up @@ -1806,7 +1806,7 @@ the Relying Party Instance SHALL perform the following steps:
2. The Relying Party Instance SHALL inspect the MSO or SD-JWT of the
attestation to see if it contains Attestation Status List information.
If so, the Relying Party Instance SHALL use the inspection procedure
specified in \[JWTStatusList\][^21] to find out the current status of
specified in \[JWTStatusList\][^20] to find out the current status of
the attestation.
3. The Relying Party Instance SHALL inspect the MSO or SD-JWT of the
attestation to see if it contains Attestation Revocation List
Expand Down Expand Up @@ -2255,7 +2255,7 @@ In essence, a Relying Party authentication mechanism works as follows:
1. The Relying Party Instance SHALL create a signature over some data in
the protocol for the request, using a Relying Party Instance private
key.
2. The Relying Party Instance SHALL include its certificate[^22] (and all
2. The Relying Party Instance SHALL include its certificate[^21] (and all
other certificates in the trust chain leading up to its trust anchor)
associated with the private key in the request. The certificate SHALL
be signed (directly or indirectly) by a Certification Authority, whose
Expand Down Expand Up @@ -2669,15 +2669,15 @@ C., Zundel, B., and D. Chadwick, "Verifiable Credentials Data Model
Looker, "OpenID for Verifiable Presentations", 30 December 2022,
<https://openid.net/specs/openid-4-verifiable-presentations-1_0.html>

\[OpenID4VCI\] Lodderstedt, T., Yasuda, K., and T. Looker, OpenID for Verifiable Presentations – draft 18, 21 April 2023[^23] Retrievable from [OpenID for Verifiable Credential Issuance - draft 12](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html)
\[OpenID4VCI\] Lodderstedt, T., Yasuda, K., and T. Looker, OpenID for Verifiable Presentations – draft 18, 21 April 2023[^22] Retrievable from [OpenID for Verifiable Credential Issuance - draft 12](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html)

\[Prop_eIDAS\] COM(2021) 281 final

\[SIOPv2\] K. Yasuda, T. Lodderstedt, M. Jones, "Self-Issued OpenID Provider V2", 1 January 2023, https://openid.net/specs/openid-connect-self-issued-v2-1_0.html

\[DP_Revoc\] eIDAS Expert Group WG1 Discussion Paper Revocation for PID and (Q)EAA, v.1.0

\[SD-JWT\] Selective Disclosure for JWTs (SD-JWT) draft-ietf-oauth-selective-disclosure-jwt 04, 11 April 2023[^24]
\[SD-JWT\] Selective Disclosure for JWTs (SD-JWT) draft-ietf-oauth-selective-disclosure-jwt 04, 11 April 2023[^23]

\[W3C StatusList2021\] <https://w3c-ccg.github.io/vc-status-list-2021/>

Expand Down Expand Up @@ -2742,33 +2742,33 @@ https://www.w3.org/TR/json-ld/
accreditation and market surveillance relating to the marketing of
products and repealing Regulation (EEC) No 339/93

[^15]: Please note that work on further specifying the EUDI Wallet
[^14]: Please note that work on further specifying the EUDI Wallet
Instance Attestation is planned to be carried out. This section may
need to be revised depending on the results of that work. For
instance, EUDI Wallet Instance Attestation may not be issued in all
cases nor are alternative possibilities excluded from consideration.

[^16]: The ARF implicitly requires device binding for the Wallet Instance
[^15]: The ARF implicitly requires device binding for the Wallet Instance
(by requiring support for ISO/IEC 18013-5 and SD-JWT)

[^17]: Preferably the same Issuer that also signed the other attributes
[^16]: Preferably the same Issuer that also signed the other attributes
that were released. However, the combined presentation of attributes
originating from different attestations will be further detailed in
a future version of this document.

[^18]: Note that this implies that Relying Parties SHALL also trust
[^17]: Note that this implies that Relying Parties SHALL also trust
device binding, see section 6.2.3.4. The Relying Party trusts that
the attestation is bound to a device trusted by the Provider, and
subsequently trusts that this device has properly authenticated the
User.

[^19]: A PID MAY be an exception: because the concept of a PID is new, it
[^18]: A PID MAY be an exception: because the concept of a PID is new, it
is not known yet what validity period PID Providers will use for
their PIDs, and if there will be a difference between the
administrative validity period as seen by the User and the
cryptographic validity period of the attestation.

[^20]: In this case, an alternative to revocation is that the pharmacy
[^19]: In this case, an alternative to revocation is that the pharmacy
backend marks the prescription as used, and all pharmacies check that
backend before handing out the medicines. This goes in fact for any
attestation: if there is a backend system that allows Relying Parties
Expand All @@ -2777,22 +2777,22 @@ https://www.w3.org/TR/json-ld/
exists for all attestations that can be ‘consumed’, i.e., that must
become unusable once they have been used.

[^21]: The current version of \[JWTStatusList\] does not explicitly
[^20]: The current version of \[JWTStatusList\] does not explicitly
describe such a procedure. The EC will point out to the authors that
this should be added.

[^22]: Please note that the term "certificate" does not mean only X.509
[^21]: Please note that the term "certificate" does not mean only X.509
certificates, but it includes also other formats of certificates,
such as in Distributed Ledgers.

[^23]: The exact version to be referenced is to be determined. \[ARF\]
[^22]: The exact version to be referenced is to be determined. \[ARF\]
references v0.14 of 30 December 2022. Draft 18 is the latest version
available at the time of writing of this document. The level of
interoperability between these versions is not known. As \[OpenID4VP\]
is still under development, presumably later versions will become
available over time.

[^24]: The exact version to be referenced is to be determined. Draft 18
[^23]: The exact version to be referenced is to be determined. Draft 18
the latest version available at the time of writing of this document.
The level of interoperability between these versions is not known. As
\[SD-JWT\] is still under development, presumably later versions may
Expand Down

0 comments on commit 2360dea

Please sign in to comment.