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

Support for Federations and Trust Schemes, removal of termsOfUse #43

Closed
wants to merge 4 commits into from
Closed
Show file tree
Hide file tree
Changes from 1 commit
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
35 changes: 0 additions & 35 deletions examples/request/vp_token_federation.json

This file was deleted.

37 changes: 7 additions & 30 deletions openid-4-verifiable-presentations-1_0.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
peppelinux marked this conversation as resolved.
Show resolved Hide resolved

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.
peppelinux marked this conversation as resolved.
Show resolved Hide resolved

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.
peppelinux marked this conversation as resolved.
Show resolved Hide resolved
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think an example of how to use a filter property would be helpful?
so the idea is that the credential contains a claim that expresses a trust framework that the issuer of that credential belongs to and verifier must know that claim and put restrictions on that claim using PE, correct? if so, explaining this a little more would help.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, I'll try to put in the form of comments some proposal before the commit for your kindly review


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":"<uri that identifies this type of terms of use>",
"federations":[
"<list of federations/trust schemes the Credential Issuer asserts it is a member of>"
]
}
]
}
```

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

Expand Down Expand Up @@ -1776,4 +1753,4 @@ The technology described in this specification was made available from contribut

-00

* initial revision
* initial revision