[Openid-specs-ab] Issue #1299: Binding between IA's claim set subject and IdA's ID Token subject (openid/connect)

Edmund Jay issues-reply at bitbucket.org
Thu Aug 19 08:12:14 UTC 2021


New issue 1299: Binding between IA's claim set subject and IdA's ID Token subject
https://bitbucket.org/openid/connect/issues/1299/binding-between-ias-claim-set-subject-and

Edmund Jay:

Comments from TL regarding for [pull request #39](https://bitbucket.org/openid/connect/pull-requests/39/merging-cp-into-ca)

[https://bitbucket.org/openid/connect/pull-requests/39/merging-cp-into-ca#comment-238238024](https://bitbucket.org/openid/connect/pull-requests/39/merging-cp-into-ca#comment-238238024)

[https://bitbucket.org/openid/connect/pull-requests/39/merging-cp-into-ca#Lopenid-connect-claims-aggregation/openid-connect-claims-aggregation-1\_0.mdT93](https://bitbucket.org/openid/connect/pull-requests/39/merging-cp-into-ca#Lopenid-connect-claims-aggregation/openid-connect-claims-aggregation-1_0.mdT93)

Torsten Lodderstedt 2021-07-24

Why must there be a strong binding? In the simplest case, the user authenticates towards a claims source and confirms release of a set of claims w/o any binding to the subject identifier with the IdA. It just the fact that the same user has access to both, the IA and the IdA, in the same transaction that establishes the binding. Everything beyond this requires a common identifier between IA and IdA, which needs to be checked in advance \(e.g. a social security number\).

Nat Sakimura 2021-08-09

Without the binding, credential injection is easy. Without such bindings, the claimset cannot be trusted to be linked to the entity that is providing it to the CC.

The binding does not have to be identifier based. It could be bound by cryptographic key as well. For example, the user could demonstrate that he has the private key that corresponds to the public key included in the claimset.



More information about the Openid-specs-ab mailing list