Requesting credentials issued by a federation member

[David W Chadwick]

The current way of requesting a credential from a specific issuer is to request a match on the issuer property. But what if the RP wants a credential that is issued by any issuer that is a member of a specific federation (or trust network) e.g. a member of EduRoam. There should be a standard way of requesting this. In the eSSIF TRAIN project we have enabled this in the following way. The Issuer creates a Terms of Use object (which is a standard property from the W3C VC specification) indicating which federation it is member of. On receipt of this credential, the RP asks the federation operator if the issuer of this credential really is a member of this federation, and if it is, the VC satisfies its policy requirement.

If the group likes this solution, then we would need to document the current best practice for using the Terms of Use property for specifying federation membership. Note that the ToU property is used in general by the Issuer to place any type of constraint on the use of the issued credential. A verifier is free to follow or to ignore the ToU but in the latter case they would not be able to claim any damages or losses from the issuer by violating its terms of use.

There are two aspects to specifying this ToU:

a) specifying the ToU type i.e. that this ToU property is about a trust scheme (or trust mechanism) e.g. the TRAIN scheme

b) specifying the federation (or trust network) that operates under this trust scheme e.g. visa.net.

[Tom Jones]

This issue has already be addressed by openID federation in the simplest way. Shibboleth was the SAML trust interchange for universities. When OIDF was issued, they just create a new endpoint. Note that this allows different policy schema as well as different token formats. Much neater. Much easier.

[David W Chadwick]

I do not see how a new endpoint solves the issue. Could you please explain it. Thanks

[Tom Jones]

https://example.com/.well-known/{what-ever-formant-that is registered}?query={whatever-item-you-want}

YMMV

[David W Chadwick]

This is what the Train API gives us.

Is ABC a member of trust federation X, and if it is, which attributes is ABC trusted to put in its verifiable credentials

Can your well known port (provided presumably by X ) return these details

[Tom Jones]

it’s a computer, it returns whatever it is told to.

[Jeremie Miller]

David, one alternative approach here is for the RP to make the request to an endpoint defined by the federation as suggested in the SIOP chooser discussions. For example, the request would be to “https://something.visa.net/request” which if there’s any native app installed that is part of that federation, it would intercept the request and handle it. If none are installed, it can provide suggestions to the user for what to install or auto-redirect to a PWA/web endpoint (account chooser style).

In this scenario the RP already knows it is a federated request and can process the response accordingly.

‌

[Tom Jones]

Something is getting lost in translation. If anyone wants something from the federation authority, (or any issuer) they should just send an API request to get it.

@jeremie was describing how to find the wallet, which is the only real problem.

Btw, if the federation supplies the wallet, (or some wallet chooser on the device) the problem goes away completely. A pwa can handle the request.

[David W Chadwick]

I think we are all in agreement that the RP asks the federation authority if the issuer is part of the trust federation, and the well known endpoint can be used for this. However, this is not what my issue is about. Rather, in the open world model that VCs have adopted, there can be many different trust federations, and both the issuer and RP can be members of multiple (possibly different or intersecting sets of) trust federations. So my issue is about two things

a) how does the RP indicate which trust federations it is a member of and

b) how does the issuer assert which trust federations it is a member of

Without the above, the user/wallet would be in danger of sending VCs to the RP that can never be accepted because the issuer and RP are in different non-intersecting trust federations.

The TRAIN solution is for the issuer to insert its asserted memberships into the ToU property of the VCs it issues, and for the RP (knowing where this information is stored in a standard way) to use the presentation request message to specify the ToU values it wants the wallet to match against the VCs it has in its wallet. Then the user/wallet will only send VCs that are in a common trust federation of both the issuer and RP.

Therefore if this approach is agreed to, we need to standardise the ToU property that is used.

[Tom Jones]

ahh,, you have come to the core problem of SSI in general and SIOP in particular. There is not a defined method for the user and the RP to come to agreement on the terms of use (TOU). The lack of a common legal agreement between the user and the RP exposes the RP to uncertain legal liability which I very much doubt that they will be willing to tolerate. The idea that any message from the user could impose TOU that the RP did not even understand from a legal perspective is a killer. In fact there is currently no way for siop to progress from an RP web site to any communications between the RP and the user’s wallet.

In my approach there would be an establishment of an enduring connection between the RP and the user with a TOU that was acceptable to both - probably established by a trust authority. Then any interchange between the user and the RP would be under that TOU. The user could revoke any connection at any time, but could not impose arbitrary TOU on any message. Without an acceptable TOU there will be no adoption.

‌

[David W Chadwick]

Again we are talking at cross purposes. The ToU is not from the user to the RP but from the VC issuer to the RP. In that same way that your plastic cards today have ToUs placed on them by the card issuer, the VCs have ToUs placed on them by the VC Issuer. The users will have been bound to these ToUs in order to get the VC issued to their wallet. When the VCs are presented to the RP, it can see what these Issuer imposed ToUs are. If the Issuer and RP are part of the same trust federation, and it defined a set of ToUs, then they will both understand what these ToUs are. The user, by virtue of presenting the VCs to the RP, is agreeing to the Issuer imposed ToUs since he/she signed up to these at VC issuance time.

[Tom Jones]

Now you have lost me. What is missing from the spec exactly?

‌

Read section 3.1 of https://openid.net/specs/openid-connect-federation-1_0.html

[David W Chadwick]

As mentioned in my very first post about this topic: Specifying the ToU property so that issuers know what to store in a VC and verifiers know what to look for

[Tom Jones]

As i responded, i see no way that either an issuer or an RP could deal with dynamic TOU. I spent an hour this past week listening to a lawyer explain the TOU for TEFCA. The idea that it could by dynamically testable by issuers or rps is beyond absurd.

[Jeremie Miller]

While I agree that the ToU approach could become very complex in practice, I do think it’s a good place to start documenting and have further discussions around.

[David W Chadwick]

@Tom. There is a difference between dynamic ToU and open working. We are not talking about dynamic ToU, because the trust lists can be relatively static and only change very rarely. But if the RP is a member of n trust federations, and the issuer can be from anywhere in the world, then without a mechanism equivalent to the one suggested, it will need to ask each of its federations if the issuer of the VC it has just received is a member of it. The proposed mechanism means that the RP will only need to ask one trust federation.

[Tom Jones]

I agree with everything in that last posting. What i disagree with is the content. It should be completely adequate to include the id of the trust (authority, whatever) in the message. I completely disagree with a TOU list of details in any message that MUST be parsed by any machine that is likely to be built in the next 20 years.

[David W Chadwick]

But this is exactly what I am proposing. The ToU is already a standardised field in VCs. So it will contain its type (to differentiate it from all other ToUs) plus the ID (URI) of the trust federation.

[Tom Jones]

I guess I don’t see it that way. A tou is not a disembodied document. It is an agreement between two parties. For example a url to a tou is not immutable and a type is certainly not immutable. It might be ok to create a doi that both parties acknowledged.

[David W Chadwick]

This is not how the VC world views a ToU. A ToU is a statement made by an issuer about its terms of use. A verifier can agree to the terms or ignore them. A verifier is the root of trust and decides which VCs to accept (even ones that are revoked or expired if it wants to). In the case of this particular ToU, the verifier asks its federation root of trust if the statement made by the Issuer is true or not. It then decides whether to trust the issuer or not based on the result. In this case there is never a direct agreement between the issuer and verifier, but rather between the issuer and the federation and the verifier and the federation. Both trust the federation and both agree to abide by the rules of the federation. In this case both agree to the URI that represents the federation and it is this URI that the issuer places in the ToU.

[Tom Jones]

I find the concept of basing trust on a document that can be arbitrarily changed by one of the parties to be the equivalent of building a house foundation on sand. It can be washed away by the merest storm. That’s unacceptable to me and impericaly unworkable.

[David W Chadwick]

Again I think you have misunderstood how it works. It is true that the issuer can arbitrarily change any VC that it issues. But it is also true that a verifier can arbitrarily change its decision to trust any issuer. So the verifier does NOT believe what the issuer says about the trust federation it is a member of, from the ToU in the VC. Rather it asks the federation operator “issuer A says it is a member of your trust federation, is this true or false?” The issuer has no control over the messages between the verifier and trust federation operator so cannot affect the (presumably) honest answer that the verifier receives, and upon which it will base its trust decision. So I believe this mechanism is built on rock solid concrete, not sand.

[Kristina Yasuda]

During 2022-01-13 SIOP call, David C. agreed to provide a use-case write-up.

We discussed preparing a PR outlining how PE can be used to request a VC (presented as a VP) issued by an issuer as long as it is a federation member. Options are to define a new federation claim, use TOU claim, etc.

The comment was made that this is needed for bank and credit card use-cases, too.

[Kristina Yasuda]

PR #107

[Kristina Yasuda]

Resolving since PR has been merged