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.

Sign up for GitHub

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

Jump to bottom

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

Closed
wants to merge 4 commits into from
Closed

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

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
c0f46db
Support for Federations and Trust Schemes, removal of termsOfUse
peppelinux Sep 1, 2023
79802af
federation, text improved
peppelinux Sep 1, 2023
c72b02f
Kris comments about moving the term Trust Scheme to Trust Framework
peppelinux Sep 7, 2023
bb1d856
federation and trust framework language
Sep 7, 2023
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
View file
Open in desktop

This file was deleted.

37 changes: 7 additions & 30 deletions openid-4-verifiable-presentations-1_0.md
View file
Open in desktop
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 Frameworks

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 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/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 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.
Copy link
Collaborator

Choose a reason for hiding this comment

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

what if there is no explicit claim in the credential that conveys the federation that a credential belogs to? I am not sure the verifier can communicate using PE that "please return this credential if after obtaining the trust chain using the iss value in the credential, you are certain that the credential belongs to Federation A"?

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'd not mention any trust chain or policy since these devices are not required here but Just a shared and agreed trust framework where many entities may find themselves under the same regulation

Copy link
Collaborator

Choose a reason for hiding this comment

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

the text you have written mandates/assumes that issuers put inside a credential information about which federation that issuer belongs to, I just do not think that's the case. there are cases where iss in the credential is HTTPS and a file found by appending a .well-known is sufficient. in other places, iss is a DID and metadata with the federation information is hosted at the service endpoint obtained from a DID Document.

I suggest you file an issue first. and this PR is refactored to remove dependency on termsofuse property.


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 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

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

-00

* initial revision
* initial revision