Support for Federations and Trust Schemes, removal of termsOfUse #43
Conversation
peppelinux
requested review from
Sakurann,
tlodderstedt,
ve7jtb,
rohe and
selfissued
|
|
||
| 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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
I agree, I'll try to put in the form of comments some proposal before the commit for your kindly review
|
|
||
| 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. |
There was a problem hiding this comment.
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"?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
|
I think this PR is detrimental to implementors because it is highly likely now that the VC DMv2 will contain the Terms of Use to hold information such as trusted federations. |
|
I see the addition of data about the trust framework as a workaround to ease the processing of a credential. I agree with @Sakurann that the trust framework should be determined from the issuer. I think we need to discuss this topic further. Is there a corresponding issue? |
|
Just to confirm that the ToU property is now part of the VCDMv2 draft, and the text describing the ToU property indicates that it is inserted by the issuer to provide information to verifiers about the trust framework(s) that the issuer is a member of. Note that there are various ways that an issuer can provide information to verifiers:
We currently use all three methods, and sometimes we use more than one method for the same data. Note that the trust framework confirms the veracity of the information that the issuer releases, although it could in principle publish all the issuer's information, so that the issuer does not need to release anything! |
OID4VP is format-agnostic. Whatever we do, it should work regardless of the credential format. |
I agree. Format specific rules must go into credential specific profiles. |
|
I also agree. All credentials should be extensible. For W3C VCs, the ToU is an extension point. Other credential formats can also add extensions to indicate the trust frameworks the issuer is a member of. |
|
There is value in an informative annex giving an example of how trust frameworks can be added to a specific credential format. Using W3C VCs as the example will provide guidance to other credential formats how they might achieve this. |
|
I think both Torsten & Kristina have suggested we should have an issue (possibly more than one issue?) to discuss these issues and agree on the approach first. I'd hence propose closing this PR in a week unless anyone strongly objects, and we can continue any discussion on issues. |
|
Yes please open the other issues first, and then we can close this PR and point to the new issues. |
|
Closing as per previous comments. I don't feel sufficiently well informed to raise issues about the different problems, please feel free to raise them as issues yourselves. |
Reading the specs I’ve realized that the text pertaining the federation/trust-schemes can be simplified by giving simple indications and normative language to the implementers.
During the review phase, additional comments asked for the removal of
termsOfUse. This was accomplished in the current PR.This was manually migrated from bitbucket, where the original one is available at the following link:
https://bitbucket.org/openid/connect/pull-requests/587