Section 5.3 - Issue credential in the token response

[Edmund Jay]

Comments from TL :

Alternatively, the credential could be issued in the token response. That would allow to make it a one time exercise with a less risky security characteristics and always get the holder’s consent. 

‌

[Nat Sakimura]

Section 4 is Abbreviation. I think this comment was towards Section 5.3

[Nat Sakimura]

So, that’s the parallel of ID Token?

That would require the user to provide “consent” at the IA each time. Unless that “credential” is allowed to be replayed many times by the wallet, which would cause other issues, would it not be too onerous from the user experience point of view?

Good point for this approach is:

• We do not need to support a new endpoint for constrained claims access.

Disadvantages:

• Onerous user experience unless the format of the claims (“credential”) implements further selection mechanism (e.g., mDL)
• The wallet needs to implement such selection mechanisms.
• A replay of the issued “credential” would have different security and privacy characteristics, depending on “credential” format.

‌

‌

[Tobias Looker]

Originally in Credential provider we supported obtaining the credential only via the token response, however this was limiting because re-issuance including credential refresh would require End-User authentication and consent eachtime. Therefore it was dropped in favour of a back-channel endpoint. Supporting both token response flow and back channel endpoint in my opinion would make the protocol more complex and potentially harm interoperability.

[Nat Sakimura]

I agree with Tobias, but it may also be good to hear back from product developers as well. > @ Vittorio.

[Jeremie Miller]

We have a roadmap to support single-use credentials (one presentation per credential) which can be fetched in small quantities and cached a short time for offline use-cases.

This pattern only works well with a back-channel endpoint, which also offers the advantage of using a scope’d access token to a dedicated credential issuance service.

Even though we don’t have any current plans to utilize credentials issued as part of the token response it is probably a simpler option for other use-cases.

I’m not sure it’s possible to pick one or the other?

[Nat Sakimura]

So, back-channel endpoint approach covers token endpoint use-case as well. The token endpoint approach does not cover the back-channel endpoint use-cases. Thus, if we were to pick just one, it will be the backchannel endpoint approach.

We could potentially support both but the downside is:

• More effort to implement and support two ways of doing it for developers on both server and client products.
• Less certaininty about what is being supported from the point of view of the deployment, i.e., interoperability issues. This may potentially be somewhat alleviated by mandating the backchannel endpoint approach as mandatory to implement (MTI). In this case, we will need server metadata to represent the option as well.

‌