sender constraining of attached document access token

[Joseph Heenan]

The text in https://bitbucket.org/openid/ekyc-ida/pull-requests/50 explicitly mentions bearer tokens when talking about access tokens.

We should at least make clear that when using the OP’s access token then sender constrained tokens (MTLS, DPoP) can be used.

When not using the OP’s access token (i.e. an access token is provided for the particular resource) it’s not clear if the token can be sender constrained.

An additional consideration is that the protocol doesn’t define a way to prevent the client from supplying an access token to the resource, potentially meaning an unnecessary access token is sent out and presents an unnecessary vector for the token to be leaked.

[Mark Haine]

we discussed on 21/04/2021 and agreed to discuss with Torsten and Daniel once Joseph has a bit more time available.

[Torsten Lodderstedt]

we came to some conclusion: we could add a field indicating to the RP that the particular access token is sender constrained. The concrete mechanisms and key to be used would be the same used to protect access to the endpoint used to obtain the assertion containing the artifact reference.

Examples:

• mTLS (RFC 8705) protected token is used to query the user info response → access token is bound to mTLS and certificate used on that request
• DPoP protected token is used to query the user info response → access token is bound to DPoP and certificate used on that request
• mTLS (RFC 8705) bound access token is issued in token response along with id token containing an artifact reference + access token → access token is bound to mTLS and certificate bound to OP access token
• DPoP (RFC 8705) bound access token is issued in token response along with id token containing an artifact reference + access token → access token is bound to DPoP and certificate bound to OP access token

‌

[Kai Lehmann]

Unfortunatelly, I won’t be able to join today. After partially reading through the respective specs I agree that we should allow for sender constrained tokens as well. We could update the text to state as much at least. That said, I’m not sure if we should explicitely mention DPoP or MTLS in the IDA spec. I would rather expect to have the specs of MTLS and DPop explain how they could be used as drop-ins for standard bearer tokens. In the end, it is just something, what IdP and OP need to agree upon.

As far as I understood DPoP, the access token used to query the user info endpoint cannot be used to access the attachments, as those attachments have a different htu. So the client would need to use the token endpoint of the auth server to request an access token for each of those attachments.

[Kai Lehmann]

PR#76 only addresses the token type part.

@Joseph Heenan you mentioned another concern about leaking tokens to Resource Servers which should not receive them. I intended to require the OP to protect those documents. The attachments can only be requested with proper authorization. The client must provide an Access Token for this. Simply uploading those sensitive documents to Amazon S3 and thus making them available for everyone to download without proper authorization would violate this requirement. After reading the attachment part again, I can see that this requirement for the OP to protect those resources is not clear enough.

[Kai Lehmann]

As @Joseph Heenan and @Torsten Lodderstedt had to drop out, we agreed that I first summarize what I intend to do here in the issue and if there is no objection, I will update the PR to reflect the following:

• If Token is provided in the attribute, this token MUST be used as bearer token, unless otherwise negotiated between RP and OP
• If token is not provided in the attribute, the token used for accessing the user info endpoint MUST be used and it must be presented the same way when accessing the attachments. unless otherwise negotiated between RP and OP
• The negotiation is outside of the scope of this specification

‌

[Torsten Lodderstedt]

We had also discussed to indicate to the RP that no access token shall be sent with the request for the attachment. To me this means, if the OP does not provide an access token it must also additionally indicate the “mode of operation”, whether it is “use same access token” or “don’t use an access token at all”.

[Kai Lehmann]

This is what “. unless otherwise negotiated between RP and OP” in item 2 should be for. it’s maybe not clear enough from the sentence, but the “unless” applies to providing an access token at all. You mentioned in the call something like having a “none” value to indicate that no access token should be sent. After this we argued whether we should actually promote this or rather still make it a MUST, but allow a negotiation between RP and OP to opt out of it outside of the specification in which case we should at least mention that the OP has to consider this security risk.

That said, if we want to include the option to not have an access token at all, we could define access_token: null or access_token: false. This way, the type of the attribute can be used to differentiate on RP side. As far as I can see, JSON schema supports multi types.

[Torsten Lodderstedt]

“unless otherwise negotiated“ opens a door, but it is not an interoperable approach. I’m in favor of an interoperable approach. Whether we support no access token (which does not mean unprotected) or whether we only have the two options you mentioned to me, I don’t care as long as the text is clear.

[Kai Lehmann]

PR#76 addressing both concerns has been merged.