Section 3 - Require Sender Constrained Tokens

[Edmund Jay]

Comments from TL regarding original Credential Provider spec:( #1268 ) and Comments from TL regarding for pull request #39 (https://bitbucket.org/openid/connect/pull-requests/39/merging-cp-into-ca#comment-238239085)

‌

It seems the OP is required to issue an access token good to obtain credentials bound to arbitrary DIDs. This means that this access token is a very powerful credential. I think bearer tokens are not suitable in this case and recommend to make sender constrained access tokens (using mTLS or DPoP) mandatory.

‌

‌

[Nat Sakimura]

On Nov. 16 call and in one of the previous call, callers pointed out that mandating sender constrained access token here is not a good idea as it would risk of being it ignored.

[Kristina Yasuda]

Alternative to mandating a sender-constrained Access Token like in PR #63 would be to prevent binding to arbitrary DIDs or arbitrary cryptographic material.

We could pass a signature signed using a private key to which the user is requesting issued credential to be bound to as a proof. To prevent that proof from being replayed, we could pass that proof after receiving an access token and include hash of an access_token in that proof as a challenge.

+ I understand the importance from a security perspective, but I agree with the comment made during the Connect call that requiring mTLS and DPoP might be a high bar of a requirement that will scare implementor’s away

(cc @Torsten Lodderstedt )

[Nat Sakimura]

Looks like there is no consensus on requiring sender constraint tokens throughout.

[Nat Sakimura]

The WG callers agreed on Dec 13/14 call if we are going to mandate sender constrained tokens, that probably should happen in the Core as Connect Core 1.1 or something with DPoP.

[Edmund Jay]

fixes #1284 - Require Sender Constrained Tokens

Removes mention of MTLS and DPoP per WG decision

→ <<cset 209db137c989>>