Administrative Trust in the RP
Issue #1551
resolved
Wallets may need to decide if RPs are administratively trusted prior to asking the user for consent to send credentials to the RP. (Note administrative trust is not the same as cryptographic trust, which can be established with a TLS link to the RP.) We have already specified a mechanism for RPs and wallets to administratively trust issuers, regardless of the trust infrastructure used, and we need a similar mechanism to enable trust in RPs. The following methods are suggested:
- The RP adds a trust_federation property to its metadata, listing the names of the trust federations that it purports to be a member of;
- The RP sends its trust_federation property values to the wallet along with the presentation request.
Note that the trust federation property values asserted by the RP may be true or false. It is the responsibility of the wallet to determine whether any of the values are true or not by using the method specified by its trust infrastructure. The inputs to this algorithm are: the name of the RP and the name of asserted trust federation.
Comments (54)
-
-
This issue seems somewhat meta. I’m trying to figure out what the pull request corresponding to this issue would look like. On one hand, OpenID Connect Federation already includes such a mechanism. But what other mechanisms would we also want to specify and what would we want to say about them?
-
David presented this issue under oidc for verificabile presentation, and we're talking on oidc Fed.
In oidc 4 VP we do not have the trust marks or no one has tried to use these concretely
-
reporter
@Mike. You are right, this is a meta issue, as it is independent of the trust federation that has been adopted. I can do a pull request for you to see what it would look like.
-
Could we simply mention the possibility of using request objects with an
x5cheader claim and leave it up to the wallet designer to design conventional trust chains? -
yes it’s a common strategy, however considering that a RP may belongs to different federations and trust frameworks, does it need to use different x509 certificate chains for different audiences (OP)? This is a problem that oidc federation resolve by design.
-
reporter
@Thomas. Unfortunately the x5c does not solve the problem of administrative trust since an RP with one X509 PKC could be a member of different trust federations, and none of them need be related to the CA that issued the RP with its PKC.
-
reporter
Created PR
#255to address this issue -
SIOP call: agreed to discuss and agree on the syntax to use in PR #255 in this issue first
-
reporter
The syntax that is being proposed consists of two mandatory properties
- The URI of the type of trust framework. This is a globally unique URI which is known by all members of the trust framework. Examples would be URIs for OIDC Federation, Yes, and TRAIN.
- The identifier of the specific trust framework that is of the above type. The ID is a string and the contents of the string are determined by the type of trust framework. For example, OIDC Federation could decide it is the URI of the trust anchor, or a JWK created by the trust anchor. For TRAIN, it is the DNS name of the trusted federation operator.
there is also an optional parameter, info, which is a URL pointing to a web page where additional info about the type of trust framework can be found.
If anyone has an alternative syntax to propose, could they please describe it. Thanks.
-
I think it is useful to allow for multiple trust frameworks and to also allow for multiple trust protocols as it is entirely likely that htere will be implemetations using various trust protocols.
Also, there is a little conflict here with what has been done in OIDC4IDA which uses the
trust_frameworkclaim to provide a link to the policy domain rather than a link to a technical trust network. Allowing for both would seem useful and aligning claim names would be a good idea I think. -
reporter
@Mark Can you please suggest the claim names to be used as I am not wedded to any particular claim name. As long as the claim names are meaningful that is good for me.
-
perhaps
federation_address? -
reporter
@Mark
I think it is useful to allow for multiple trust frameworks. This is the intention. What we need is a term for this property, so that the value is the ID of the specific trust framework such as OpenID Federation, TRAIN, or Yes etc. -
we do not seem to have a mutual agreement on what “trust framework“ ie. OIDF is not a trust framework, nor yes.com in my mental model. see openid / connect / Pull Request #255: Determining if one party may be able to trust a second party. — Bitbucket
-
reporter
Yes we all agree that a (new) name is needed to describe what model a federation uses for establishing trust. In GAIN all three methods: OID Federation, yes.com (proprietary) and TRAIN, are recorded as federation specific trust establishing mechanisms. Discussing this with Guiseppe we suggest something like this for the property name:
trust_x_supported
where x is the name we are looking for. Candidate terms for x are: negotiation_methods, methods, mechanisms, establishing_methods. I guess that bikeshedding is needed to agree on the best semantic term.
-
As I commented in the PR, not all trust frameworks are instantiated as federations. Any solution we include needs to be reflective of that reality.
-
reporter
I think you should find that the proposed new text reflects this reality.
-
As far as I understand, David wants to establish a mechanisms to indicate to the wallet what kind of trust management the RP wants to (technological side) and also pass parameters of the respective mechanism (context). That could be (for example)
- x.509/list of CAs
- OIDC federation/entity_id
- TRAIN/trust_framework_operator
I think that’s a very important topic to solve.
I would like to point our there is existing text in the OpenID4VPs spec (https://openid.bitbucket.io/connect/openid-4-verifiable-presentations-1_0.html#name-obtaining-client-metadata) with some overlap that we need to consider.
8.2.1.2. Alternative Methods
When the request is signed, the mechanism depends on the syntax of client_id and the resolution method used. Resolution methods are defined in Section 9.2.2 og [SIOPv2].
If client_id is a HTTPS URL, client_id is resolved to obtain all Client metadata from an Entity Statement as defined in [OpenID.Federation].
If client_id is a Decentralized Identifier, the public key is obtained from a DID Doc as defined in [DID-Core] and the rest of the metadata is obtained from the client_metadata (or client_metadata_uri) parameter.
-
Per discussions on the 10-Nov-22 SIOP special topics call, PR #255 was closed due to lack of consensus on the specifics of what to do. Conversations should continue in this issue.
-
reporter
Here is a fully worked out proposal for the PR. This is what we are currently implementing in the NGI Atlantic project.
- The user browses the web and interacts with a new RP.
- After visiting all the public pages, the user finally wants to access a protected page.
- After clicking on the protected page’s entry button, the browser is sent the OID4VP request message to be redirected to the wallet (or the wallet could be asked to scan in a QR code).
- The two most important parameters of the request message are the client_id and the trust_methods_supported parameters. The client_id must contain the asserted URL of the RP. (Note it does not matter if this is true or false information as the wallet will determine if it is trusted or not.)
- The wallet looks at the trust methods supported and if it does not recognise any of them, it tells the user “warning this RP cannot be trusted. Do you want to proceed”……
- If the wallet recognises a trust method X that they have in common, the wallet calls its local X procedures to ask if the RP with URL <client_id> is trusted.
- Assuming the RP’s client_id is trusted, the wallet will subsequently ask the user for consent to send the VCs to <client_id>. The wallet then retrieves the metadata of the RP from <client_id>.well-known. (Note. We will need to register the well known for trusted RPs).
- The metadata returns the redirect_url for the VP to be returned to. The wallet now knows this is a trusted endpoint to send the user’s PII to, because the RP’s client_id URL is trusted, so the metadata at well-known is trusted, so the return_url is trusted.
- What if the RP and wallet use different trust methods? GAIN has a solution for this. Both trust methods must implement an adaptor to connect to GAIN, which uses OIDC Federation. Now the RP will publish that its trust methods supported are Y and GAIN/OIDC Federation. The wallet will have adaptor code built in that allows its trust method X to find out about GAIN members. When the wallet gets a match on the GAIN trust method, it calls its local X adaptor code to ask if client_id is a member of GAIN and will get a positive answer. The wallet then proceeds as before and fetches the metadata of the RP from the well-known endpoint.
-
Step 7 assume the wallet always retrieves client metadata from <client_id>.well-known. I guess this step should be trust method specific (as well as the interpretation of the structure of the client id). The concept also needs to cater for different ways of verifier authentication.
For example, if the RP uses x.509 as trust method, the client id could be its DN and the metadata could be obtained from the x5c header in the signed authorization request. Similar, OpenID federation fetched the data from a different location and the client is supposed to use PAR or a signed request for authentication.
-
reporter
If people are happy with the above what do you suggest for the well known endpoint. Suggestions are “rp_configuration” or “verifier_configuration” or “openid-credential-verifier”
-
reporter
@torsten Retrieving the OIDC4VP metadata is not trust method specific but is OIDC4VP specific since this is a part of the OIDC4VP standard.
If the RP using x.509 then the subject alt name and the common name are the DNS name of the web site. In which case the DNS name should match the client_id
-
In my opinion, we discuss retrieval of OAuth client metadata, this is by no means limited or dedicated to OpenID4VP. Or do you want to specify a different facility for SIOP and another one for plain OAuth? What if the same client uses all of them in a single request (e.g. to get a VP along with a cryptographically bound sub and an access token to initiate a payment)?
-
reporter
Yes this is (enhanced) OAuth client metadata. I think the same trust enhancing mechanism can be used for SIOPv2 as well as for OID4VPs. (I only said this is what we are implementing in NGI Atlantic because we are only fetching a vp_token and not an id_token - but the same mechanism can be used for both). Note also that this mechanism is used for a new unknown RP/client talking to the wallet for the first time. Known RPs will not use this mechanism because presumably they are already trusted and already have a client_id assigned by the wallet AS. So the RP will not need to send trust_methods_supported in the intial request to the wallet.
-
We discussed this on the 8-Dec-22 SIOP call. People are asked to weigh in on the issue whether they want to see this functionality added, and if so, whether they agree with the mechanism that David proposed in his 11-Nov-22 comment or whether they’d like to see specific changes to it.
-
- changed status to open
-
I would prefer to have a single parameter, like client_type, that determines how the client id and other metadata need to be handled (including trust management). The client_type value would determine what further parameters should/must be present in the request.
I don’t think the same client id (in general) will work with multiple trust methods, like X.509 or OpenID Connect Federation, simply because they all require a certain syntax of the client id, for example a Distinguished Name for X.509 and a URL for OIDC Federation.
Clearly, if the mechanisms allows a certain client to be part of multiple federations that should be possible to support (through trust management method specific parameters).
I tried to capture this in the following deck along with ideas for evolving OIDC federation (https://docs.google.com/presentation/d/1BRVrMSY7fbVOtQz-neomvi8Txm24IpbCQMzgB4R7q28/edit#slide=id.g198a0db2fb4_0_21).
-
reporter
Your client_type is equivalent to my trust_methods_supported which is also a type. Both are URIs. So now we are only debating what name to give this URI property. Let's call it X for now.
So the RP sends X=someURI to the wallet AS, and the AS looks to see if this someURI is known and supported. If not, the RP cannot be trusted. This is my step 5 above. If X=someURI is known and supported, then this type provides additional method specific parameters. So I think we are in agreement conceptually.
We have implemented this model for both GAIN (OIDC federation) and TRAIN, both of which I understand. In both these cases the only other parameter that is needed by the AS is the root of trust defined in the language of someURI. This root of trust is called the trust anchor in GAIN, the trust anchor CA in X.509, and the trustScheme in TRAIN (different names for the same concept). Does yes.com have a similar concept as the root of trust for its federation? If so, this root of trust is what the RP would provide for its additional parameter if it sent X=yes.comURI.
Essentially what the RP is saying to the AS is the following
- I am a {member of a trust method | a client of type} X called someURI and
- The root of trust of my federation is <SomeRootOfTrust> defined in the syntax used by someURI (i.e a DNS name for TRAIN, an X.509 CA PKC for X.509, a URL for GAIN/OIDC Federation)
Armed with these two pieces of information, the AS knows how to make outgoing calls in its federation using the protocols defined by someURI, to ask if the RP is trusted by <SomeRootOfTrust>.
-
Do you assume X contains a single value or multiple values?
PS: yes uses a v4 UUID as client id and our account chooser (its URL) functions as trust anchor.
-
reporter
Yes I assume that X is a set. The reason is simple. Yes.com has its own proprietary trust method (URI-yes), but when it joins GAIN it also supports this trust method (URI-GAIN). The same is true for our TRAIN members. If we only allow X to be a single value then TRAIN members could never trust yes.com members as you would not trust URI-TRAIN and we would not trust URI-yes. But with a set, both members now have a set comprising URI-GAIN and their own proprietary trust method. Now we know we can trust each other by using the URI-GAIN trust method. (And both of us have written adaptors from our proprietary scheme to GAIN, to allow us to interwork).
The adaptor from GAIN to TRAIN is actually very simple in our wallets, as we only have to remove https:// from the GAIN trust anchor to get the TRAIN DNS trust scheme.
-
I understand your rationale. However, I see a conflict with the way clients work in OAuth. Based on our experience in GAIN, I would assume every entity would have dedicated client ids for every trust method. Just as examples: OpenID Connect Federation uses a https URL and yes.com uses a v4 UUID, so being part of two different kinds of federations requires different client ids.
OAuth expects a client to send exactly one client id with a request. So in order to be compatible with OAuth, we cannot have more than a single id. I don’t think this is a real problem as I assume the client can determine what trust methods a certain AS supports in advance of the actual request, i.e. the client can customize the client id and all related data to the particular AS.
I would like to come up with a solution that works for OpenID4VP & OpenID4VCI but can also used for any other kind of OAuth deployment (as this challenge is not VC specific). My goal is to spin up a new IETF draft and bring it to the OAuth WG.
I suggest to introduce a parameter
client_id_formatdetermining the format of the client id and with that how it must be interpreted and processed by the AS. The value will also determine what additional parameters can/need to be sent with the request. Such a parameter would allow us to simplify the currently rather complex request processing logic (signed/unsigned request, client id equals redirect uri, OIDC federation, DID) and make it modular.Candidates for formats are:
opaque: that’s the RFC 6749 default. The AS needs to know the client id in advance.redirect_uri: the client id equals the redirect URIopenid_connect_federation_entity_id: the client id is an OIDC federation entity id, a further parameter trust_list can be sent with the request to provide entity statements, the request must be authenticateddid: the client id is a DID. The request must be signed with a private key associated with the DID.x509_dn: the client id is an X.509 DN, the request must be signed with the X.509 cert, the cert is provided in the request (x5c header of the request object)train: <please fill in>
Feedback welcome!
-
So the request would add
client_id_format, eg?client_id_format=openid_connect_federation_entity_id&client_id=https://rp.oidc-federation-online ...I’m ok with this proposal, the only objection is the further parameter trust_list related to oidc federation. Formally, trust list is a term belonging to the eIDAS architecture and not to OIDC Federation. Moreover the federation entity discovery requires the fecth of the leaf’s entity configuration, the following of the authority_hints parameter, the fetch of the entity configuration of the superior and then the fetch of the entity statement issued by the superior for the descendant leaf. To avoid the entity discovery process the leaf should submit the trust_chain paramenter in the request. Usign the trust chain paramenter in the request there’s no need to have the trust_list parameter.
-
Sorry, I should have checked the parameter name. I meant
trust_chain.Here is the adapted text proposal:
openid_connect_federation_entity_id: the client id is an OIDC federation entity id, a further parametertrust_chaincan be sent with the request to provide entity statements, the request must be authenticated
-
So this is essentially switching the entire OIDC “profile”, ie much more than just the client ID format.
-
It switches the way the client data is processed but there is no impact on other aspects of OAuth or OIDC or OID4VCs.
-
I’m ok with this proposal @torsten, and thank you for having clarified that typo.
trust_chain is not a required parameter, if absent the trust verifier should follow the federation entity discovery process.
sounds good to me, very interesting feature to deal with different trust mechanisms and infrastructures
-
Profile in the sense “now we have OIDC Federation 1.0 kicking in, else even if the client_id appears to be a federated entity ID URL, e.g.
https://rp.example.com, ignore that".Do any of the proposed “candidates” at spec level need to be aware of this switching parameter?
OIDC Federation 1.0 need not. I’m not sure about the other specs.
-
Do any of the proposed “candidates” at spec level need to be aware of this switching parameter?
Not as far as I know. In the end it is the AS that needs to decide to what spec it shall conform in a certain transaction.
-
reporter
@ Torsten For TRAIN, the client_id is being stored as the ETSI parameter
<ServiceSupplyPoints><ServiceSupplyPoint>https://rp.research.identiproof.io/</ServiceSupplyPoint></ServiceSupplyPoints>which is also the OAuth2 prefix for the client’s well known metadata. In this way the wallet knows that the client_id is trusted (because TRAIN says it is), then it knows that the client’s metadata is also trusted (because it is retrieved from the well known endpoint - not any random endpoint). The redirect URL (and other info) can be obtained from the trusted metadata
@ Guiseppe “To avoid the entity discovery process the leaf should submit the trust_chain paramenter in the request.”
My proposal for trust_methods_supported is that once the type is defined (in your case OIDC Federation) the next parameter(s) are determined by the type. So it is OK for you to provide the trust chain if you want to as an optional parameter. The mandatory parameter should be the trust anchor. This is because you have to consider how the Adaptor code in the wallet will work. If the wallet only supports Yes.com or TRAIN, and not OIDCF, then it has to have an adaptor that knows how to convert the trust anchor (or optional trust_chain) into what it needs to call its existing trust method (e.g. Yes or TRAIN). Otherwise you are requiring the wallet to natively support OIDC Federation (which might be OK once open source code is available for Android and iOS, but not before). In the case of TRAIN, the GAIN adaptor code is simple. Strip https:// from the GAIN trust anchor to get the DNS name (used by TRAIN).
-
reporter
@ Torsten. For TRAIN the client_id is a URL that is used twice
firstly it is included in the ETSI Trust list in the Service Supply Point for the verifier
<ServiceSupplyPoints><ServiceSupplyPoint>https://rp.research.identiproof.io/</ServiceSupplyPoint></ServiceSupplyPoints>So the wallet now knows if the client_id can be trusted or not.
Secondly it is combined with the well known endpoint for the client’s metadata. The wallet now knows that the client metadata can be trusted (because it must exist at the well known, and not anywhere the client may choose)
Note that this parameter is a set, so an RP can have a set of client_ids.
-
reporter
@ Guiseppe. The supported_trust_methods allows every trust method to specify its own parameters. So OIDC Federation can specify an optional trust_chain as well as a mandatory trust_anchor. Note that the Adaptor code in the wallet will need to know how to convert the trust anchor into whatever its equivalent is in its own trust method, assuming it currently only supports its own trust method. For TRAIN this is easy, as simply stripping off the https:// from the trust anchor leaves the TRAIN trust scheme DNS name, which TRAIN uses to determine if an RP is trusted.
-
reporter
@ torsten. I am not sure how you propose to solve wallet trust in yes.com RPs, for wallets that do not understand the yes.com trust method. This is because the wallet needs to know two things from a trust perspective (at least):
First, the RP with client_id X is trusted by the trust infrastructure, and
Secondly, the metadata that the RP is asking the wallet to read actually belongs to the client_id X.
The wallet cannot trust the RP to assert either its client_id or metadata URL as the RP can assert anything for these fields. So the trust infrastructure must validate both of them. Of course when the client_id is a URL then once the client_id has been validated by the trust infrastructure the well known end point can be used to pick up the RP’s metadata
-
Note that this parameter is a set, so an RP can have a set of client_ids.
That’s fine from a trust infrastructure perspective. However, an OAuth authorization request can only be performed using one of those client ids.
@ torsten. I am not sure how you propose to solve wallet trust in yes.com RPs, for wallets that do not understand the yes.com trust method. This is because the wallet needs to know two things from a trust perspective (at least):
…
The trust needs to be established using the rules and processes defined by the respective trust management mechanism.
My proposal does not change those specific rules.
My proposal allows the RP to declare what kind of client id (and with that what kind of trust management mechanism) it wants to use for a certain request. This makes the process unambiguous and modular. Unambiguous because there is no longer the need for the wallet to somehow detect what trust management mechanism the client might want to use (by parsing and interpreting the client id). Modular, because new trust management mechanisms can be added at any time and every participant can publish its supported mechanisms in its metadata.
-
My proposal allows the RP to declare what kind of client id (and with that what kind of trust management mechanism) it wants to use for a certain request. This makes the process unambiguous and modular. Unambiguous because there is no longer the need for the wallet to somehow detect what trust management mechanism the client might want to use (by parsing and interpreting the client id).
In the case of OIDC Federation 1.0 the guesswork does have an associated cost, like initiating an HTTP GET if the client_id looks like a URL, which can cost a second or even longer depending on timeouts and network. So letting the client state upfront what it actually is seems a good idea.
This will also prevent clashes between profiles (okay, that’s probably not the right word, is trust framework better?) which make the client_id a URI or URL. Because OIDC Federation 1.0 has now effectively taken the URL format, but this shouldn’t block other mechanisms from benefiting from it.
-
reporter
@ Torsten. If I understand you correctly, an RP that supports more than one trust method will have to create multiple different authz requests (one for each trust method), and then decide which authz request to send to each wallet that contacts it.
My proposal is that the RP sends the set of trust methods that it supports to the wallet, and the wallet chooses the one that it supports. This seems far simpler all round, providing we can solve the single client_id issue.
-
reporter
In OIDC4VCI we already agreed that the mandatory OAuth2 client_id is optional. So in OIDC4VP we can agree that a set of client_ids should be possible (one for each trust method)
-
In OIDC4VCI we already agreed that the mandatory OAuth2 client_id is optional. So in OIDC4VP we can agree that a set of client_ids should be possible (one for each trust method)
In OIDC4VCI we defined the client_id to be optional in case of the pre-authz code. We can do this because this is possible on a per grant type basis. It does not hold for all grant types.
Furthermore, omitting a client id is not the same as allowing multiple client ids. The client id determines the identity of a certain client and the policy associated with it. Multiple client ids make that ambiguous.
And again, there is no need to have multiple client ids. The client can determine up front what mechanism to use with a certain wallet and then use the respective client id.
-
reporter
It is not ambiguous to have different client_ids for different trust_methods, because each trust_method will record the client_id specific to that method. It is completely deterministic.
-
reporter
The client cannot determine up front which trust method to use with any wallet without first communicating with the wallet (directly or indirectly) to find out which trust methods its supports. This is inefficient. Many negotiation protocols on the internet work today by the first party saying “this is what I support” and the second party picking one. This is the paradigm that the trust_methods_supported parameter follows. The client says “this is what I support” and the wallet picks one. Your proposal does not follow this paradigm as it requires the client “to determine up front” which method to use. But you have not said how this is done in the protocol.
-
I just filed PR #427 with the proposed solution.
-
PR merged, but keeping this Issue open until issue
#1798is resolved. -
- changed status to resolved
Migrated to GitHub
- Log in to comment
- Assignee
- –
- Type
- Priority
- Status
- resolved
- Component
- Verifiable Presentation
- Milestone
- –
- Version
- –
- Votes
- 0
- Watchers
- 9
We may use the trust marks as they are in OIDC Fed 1.0 attesting the comformance or the participation to a federation, in terms of proof of onboaring.
I think that it’s more than a self attestion because trust marks are signed by a trusted and well known issuer