Expand explanation of use cases #3
Description
This issue is a copy of my request on the AB/Connect mailing list. I am reposting it here to make it easier to keep track of it.
Since there has been some confusion about the use case of the draft, I think it would be worthwhile to sketch out how the "RP Authenticating Component" and "RP Consuming Component" map to at least one use case (such as OpenPubKey, which seems to be the main motivating example?).
Such a mapping would be a convincing argument that the draft solves the problems you are intending to solve, and would make it easier to "advertise" use cases of the draft to the community post-adoption.
For instance, I think it would be useful to show how the concepts of "RP Authenticating Component" and "RP Consuming Component" apply to the roles in Figure 7/Figure 11 here:
https://www.docker.com/blog/signing-docker-official-images-using-openpubkey/
Note: at the last WG call, I got the impression from @dickhardt that the use case outlined by Docker in the link above is not actually a good use case for this spec since it seems to use the ID Token as an Access Token.
If that is the case, I think it would be valuable to add an "anti-example" to show what should NOT be done (perhaps in a Privacy Considerations section).
(this issue was ported from: dickhardt/openid-key-binding#11)