From c0f46db04c24e6e442a7da762e3163783082a1ee Mon Sep 17 00:00:00 2001 From: peppelinux Date: Fri, 1 Sep 2023 19:47:39 +0200 Subject: [PATCH 1/4] Support for Federations and Trust Schemes, removal of termsOfUse --- examples/request/vp_token_federation.json | 35 --------------------- openid-4-verifiable-presentations-1_0.md | 37 +++++------------------ 2 files changed, 7 insertions(+), 65 deletions(-) delete mode 100644 examples/request/vp_token_federation.json diff --git a/examples/request/vp_token_federation.json b/examples/request/vp_token_federation.json deleted file mode 100644 index 2b6805fb..00000000 --- a/examples/request/vp_token_federation.json +++ /dev/null @@ -1,35 +0,0 @@ -{ - "vp_token": { - "presentation_definition": { - "id": "32f54163-7166-48f1", - "input_descriptors": [ - { - "id": "federationExample", - "purpose": "To pick a UK university that is a member of the UK academic federation", - "constraints": { - "fields": [ - { - "path": [ - "$.termsOfUse.type" - ], - "filter": { - "type": "string", - "const": "https://train.trust-scheme.de/info" - } - }, - { - "path": [ - "$.termsOfUse.federations" - ], - "filter": { - "type": "string", - "const": "ukuniversities.ac.uk" - } - } - ] - } - } - ] - } - } -} \ No newline at end of file diff --git a/openid-4-verifiable-presentations-1_0.md b/openid-4-verifiable-presentations-1_0.md index 877786ea..e0a03301 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -828,40 +828,17 @@ The following is a non-normative example of a set of static configuration values } ``` -## Support for Federations/Trust Schemes +## Support for Federations and Trust Schemes -Often Verifiers will want to request Verifiable Credentials from a Credential Issuer who is a participant of a federation, or adheres to a known trust scheme, rather than from a specific Credential Issuer, for example, a "BSc Chemistry Degree" Credential from the hypothetical "eduCreds" trust scheme rather than from a specifically named university. +The Verifier who wants to obtain Verifiable Credentials issued by Credential Issuer who is a participant of a federation, or adheres to a known trust scheme, MUST create a `presentation_definition` that includes a known property within such federation, that allows to distinguish the request according to it. -To facilitate this, federations will need to determine how a Credential Issuer can indicate in a Verifiable Credential that they are a member of one or more federations/trust schemes. Once this is done, the Verifier will be able to create a `presentation_definition` that includes this filtering criteria. This will enable the Wallet to select all the Verifiable Credentials that match this criteria and then by some means (for example, by asking the user) determine which matching Verifiable Credential to return to the Verifier. Upon receiving this Verifiable Credential, the Verifier will be able to call its federation API to determine if the Credential Issuer is indeed a member of the federation/trust scheme that it says it is. +To facilitate this, federations will need to determine how a Credential Issuer can indicate in a Verifiable Credential that they are a member of one or more federations. Once this is done, the Verifier will be able to create a `presentation_definition` that includes this filtering criteria. -Indicating the federations/trust schemes used by a Credential Issuer MAY be achieved by defining a `termsOfUse` property [@!VC_DATA]. +The Wallet that receives such Presentation Definitions MUST select the Verifiable Credentials that match this criteria, if one is available, to be released to the Verifier. -Note: [@!VC_DATA] describes terms of use as "can be utilized by a Credential Issuer ... to communicate the terms under which a Verifiable Credential ... was issued." +Upon receiving this Verifiable Credential, the Verifier is able to use the federation API to determine if the Credential Issuer is indeed a member of the federation that it says it is. -The following is a non-normative example of the terms of use that may be defined: - -```json -{ - "termsOfUse":[ - { - "type":"", - "federations":[ - "" - ] - } - ] -} -``` - -Federations that conform to those specified in [@OpenID.Federation] are identified by the `type` `urn:ietf:params:oauth:federation`. Individual federations are identified by the Entity Identifier of the trust anchor. If the federation decides to use trust marks as signs of whether an entity belongs to a federation or not then the federation is identified by the `type` `urn:ietf:params:oauth:federation_trust_mark` and individual federations are identified by the Entity Identifier of the trust mark issuer. - -Trust schemes that conform to the TRAIN [@TRAIN] trust scheme are identified by the `type` `https://train.trust-scheme.de/info`. Individual federations are identified by their DNS names. - -The following is a non-normative example of a `claims` parameter containing a `presentation_definition` that filters VCs based on their federation memberships: - -<{{examples/request/vp_token_federation.json}} - -This example will choose a Verifiable Credential that has been issued by a university that is a member of the `ukuniversities.ac.uk` federation and that uses the TRAIN terms of use specification for asserting federation memberships. +A Verifier that receives the Verifiable Credentials matching this criteria MUST verify the status of the Credential Issuer within the related federation. Since there may be several mechanisms to determine how a Credential Issuer can demonstrate to be part of such federation or adehere to a specific trust scheme, all about the status evaluation methods for a specific federation or trust scheme is referred to the technical specifications of these. ## Nested Verifiable Presentations @@ -1776,4 +1753,4 @@ The technology described in this specification was made available from contribut -00 - * initial revision \ No newline at end of file + * initial revision From 79802af5994d1d2a74362f39a47d28923f2ff2e2 Mon Sep 17 00:00:00 2001 From: peppelinux Date: Sat, 2 Sep 2023 01:53:12 +0200 Subject: [PATCH 2/4] federation, text improved --- openid-4-verifiable-presentations-1_0.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/openid-4-verifiable-presentations-1_0.md b/openid-4-verifiable-presentations-1_0.md index e0a03301..68d50303 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -830,7 +830,7 @@ The following is a non-normative example of a set of static configuration values ## Support for Federations and Trust Schemes -The Verifier who wants to obtain Verifiable Credentials issued by Credential Issuer who is a participant of a federation, or adheres to a known trust scheme, MUST create a `presentation_definition` that includes a known property within such federation, that allows to distinguish the request according to it. +The Verifier who wants to obtain Verifiable Credentials issued by Credential Issuer who is a participant of a federation, or adheres to a known trust scheme, MUST create a `presentation_definition` which includes information that can be traced back to a specific federation or trust scheme. To facilitate this, federations will need to determine how a Credential Issuer can indicate in a Verifiable Credential that they are a member of one or more federations. Once this is done, the Verifier will be able to create a `presentation_definition` that includes this filtering criteria. From c72b02f0791d0de05d5428a39c3672b1e4f58636 Mon Sep 17 00:00:00 2001 From: Giuseppe De Marco Date: Thu, 7 Sep 2023 13:50:12 +0200 Subject: [PATCH 3/4] Kris comments about moving the term Trust Scheme to Trust Framework --- openid-4-verifiable-presentations-1_0.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/openid-4-verifiable-presentations-1_0.md b/openid-4-verifiable-presentations-1_0.md index 68d50303..70d7df0d 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -828,9 +828,9 @@ The following is a non-normative example of a set of static configuration values } ``` -## Support for Federations and Trust Schemes +## Support for Federations and Trust Frameworks -The Verifier who wants to obtain Verifiable Credentials issued by Credential Issuer who is a participant of a federation, or adheres to a known trust scheme, MUST create a `presentation_definition` which includes information that can be traced back to a specific federation or trust scheme. +The Verifier who wants to obtain Verifiable Credentials issued by Credential Issuer who is a participant of a federation, or adheres to a known trust framework, MUST create a `presentation_definition` which includes information that can be traced back to a specific federation or trust framework. To facilitate this, federations will need to determine how a Credential Issuer can indicate in a Verifiable Credential that they are a member of one or more federations. Once this is done, the Verifier will be able to create a `presentation_definition` that includes this filtering criteria. @@ -838,7 +838,7 @@ The Wallet that receives such Presentation Definitions MUST select the Verifiabl Upon receiving this Verifiable Credential, the Verifier is able to use the federation API to determine if the Credential Issuer is indeed a member of the federation that it says it is. -A Verifier that receives the Verifiable Credentials matching this criteria MUST verify the status of the Credential Issuer within the related federation. Since there may be several mechanisms to determine how a Credential Issuer can demonstrate to be part of such federation or adehere to a specific trust scheme, all about the status evaluation methods for a specific federation or trust scheme is referred to the technical specifications of these. +A Verifier that receives the Verifiable Credentials matching this criteria MUST verify the status of the Credential Issuer within the related federation. Since there may be several mechanisms to determine how a Credential Issuer can demonstrate to be part of such federation or adehere to a specific trust framework, all about the status evaluation methods for a specific federation or trust framework is referred to the technical specifications of these. ## Nested Verifiable Presentations From bb1d85621b8b65c88d5ba076438dff79ee1d60c5 Mon Sep 17 00:00:00 2001 From: Giuseppe De Marco Date: Thu, 7 Sep 2023 13:58:18 +0200 Subject: [PATCH 4/4] federation and trust framework language --- openid-4-verifiable-presentations-1_0.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/openid-4-verifiable-presentations-1_0.md b/openid-4-verifiable-presentations-1_0.md index 70d7df0d..90197cd1 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -832,7 +832,7 @@ The following is a non-normative example of a set of static configuration values The Verifier who wants to obtain Verifiable Credentials issued by Credential Issuer who is a participant of a federation, or adheres to a known trust framework, MUST create a `presentation_definition` which includes information that can be traced back to a specific federation or trust framework. -To facilitate this, federations will need to determine how a Credential Issuer can indicate in a Verifiable Credential that they are a member of one or more federations. Once this is done, the Verifier will be able to create a `presentation_definition` that includes this filtering criteria. +To facilitate this, federations need to determine how a Credential Issuer indicates in a Verifiable Credential that it is a member of one or more federations. Once this is done, the Verifier will be able to create a `presentation_definition` that includes this filtering criteria. The Wallet that receives such Presentation Definitions MUST select the Verifiable Credentials that match this criteria, if one is available, to be released to the Verifier.