[Openid-specs-ab] Comments on Aggregated Claims/Credential Provider documents

nadalin at prodigy.net nadalin at prodigy.net
Tue Feb 2 22:25:08 UTC 2021


So JWKs have a specific schema, its not the same schema ad JSON-LD, a goal
of aggregated claims of different schemas may be problematic, so I’m not
convinced that is a goal that we should undertake



From: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> On Behalf
Of Kristina Yasuda via Openid-specs-ab
Sent: Tuesday, February 2, 2021 3:41 AM
To: Artifact Binding/Connect Working Group
<openid-specs-ab at lists.openid.net>
Cc: Kristina Yasuda <Kristina.Yasuda at microsoft.com>
Subject: [Openid-specs-ab] Comments on Aggregated Claims/Credential Provider
documents



Hi,

Below are comments/questions after reading Aggregated Claims
<https://bitbucket.org/openid/connect/src/00140ab1e32c7160ed2635ce871c555ce7
c32b75/openid-connect-claims-aggregation/openid-connect-claims-aggregation-1
_0.md>  and Credential Provider
<https://mattrglobal.github.io/oidc-client-bound-assertions-spec/#name-token
-endpoint-response>  drafts as requested during today's Connect call:



Regarding core functionality of binding claims to the key material supplied
by the Client, Aggregated Claims binds to `uid` - base64 url encoded
representation of the thumbprint of the Client’s public key used for
signing, while Credential Provider binds to `sub_jwk`- a raw key material
that is a JSON object that is a valid JWK.



Usage of `uid` seems to be a simpler approach. What would be an advantage of
using `sub_jwk` over encoded thumbprint of a public key? Assuming one of the
requirements of Credential Provider is to expand to the usage of additional
credential formats, would usage of `uid` be applicable to JSON-LD too or
does `sub_jwk` has an advantage?



Credential Provider also defines a new scope `openid_credential`. Indicating
in the request that binding is supported can be achieved through
`credential_supported` OP metadata and could work without defining a new
scope, like in Aggregated Claims document.





In addition to a binding mechanism, Aggregated Claims defines a mechanism to
request claims building up on `claims` parameter and Aggregated Claims
mechanism of OIDC, and Credential Provider defines support for additional
credential and identifier formats (such as JSON-LD, DIDs). These are not
mutually exclusive and it should be possible to fulfill requirement of both
in one document, while staying true to the scope of defining mechanism for
claims/credential binding (and of course semantics would have to align!).





Best Regards,

Kristina



  _____

差出人: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net
<mailto:openid-specs-ab-bounces at lists.openid.net> > が Takahiko Kawasaki via
Openid-specs-ab <openid-specs-ab at lists.openid.net
<mailto:openid-specs-ab at lists.openid.net> > の代理で送信
送信日時: 2020年11月17日 6:09
宛先: Artifact Binding/Connect Working Group
<openid-specs-ab at lists.openid.net <mailto:openid-specs-ab at lists.openid.net>
>
CC: Takahiko Kawasaki <taka at authlete.com <mailto:taka at authlete.com> >
件名: [Openid-specs-ab] Feedback to OpenID Connect Claims Aggregation 1.0



Hello,

This is the first feedback from me to "OpenID Connect Claims Aggregation
1.0" as requested in the last AB/Connect WG call on Nov 9.


- - - - - - - - - -

- Section 5.3: I'm not sure RS256 is appropriate as the default value for
claims_signed_response_alg. FAPI Part 2 Section 8.6 explicitly prohibits the
algorithm for security reasons.

- Section 5.4.2: Without diagrams and examples, it is difficult for me to
understand how "uid" and "cp_sub" are used for what reasons.

- Section 5.6.1: Why is it necessary to define "uid" request parameter? It
seems that the "uid" request parameter would make it possible to get
information about an arbitrary end-user who is different from the legitimate
one that is associated with the presented access token.

- Section 5.6.1: Why is it necessary to list "additional" client identifiers
in "aud"? It seems that the "aud" request parameter would make it possible
to add arbitrary client identifiers in addition to the legitimate one that
is associated with the presented access token. It seems the description was
added intentionally, but I'm not sure it's safe from a security perspective.

- "uid": In Section 5.4.2, "uid" is the thumbprint of a public key. On the
other hand, in Section 5.6.1, "uid" is an end-user's identifier. Using the
same parameter name with different meanings is confusing.

- Section 5.6.2: The 6th paragraph ("If the Aggregation Response is signed
and/or encrypted...") contradicts with other parts in the specification
itself. The specification requires that responses from Claims Endpoint
always be signed and optionally encrypted.

Editorial Issues
- "http" is used in some links.
- Link to RFC 7636 is wrong.
- Links to JW* specifications are old. They should point to IETF RFCs.
- Link to MTLS is old. It should point to the IETF RFC 8705.
- Referenced OpenID.IDA specification is not the latest one. The published
latest version is ID2.
- The list in Section 1 is not properly formatted in HTML.
- Parameter names should be monospace instead of italic.
- Section 5.4: s/Code Authorization Flow/Authorization Code Flow/
- Section 5.6.1: JSON object given to "aud" in the Aggregation Request is
wrong.
- Section 5.6.2: s/MAY elect to/MAY select to/
- More diagrams and examples are needed for readers.

To be honest, I couldn't understand the specification well due to its
complexity and lack of diagrams and examples. What is the essential
difference between UserInfo Endpoint and Claims Endpoint?

Best Regards,
Takahiko Kawasaki

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20210202/2c996523/attachment.html>


More information about the Openid-specs-ab mailing list