<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=iso-2022-jp"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"MS PGothic";
panose-1:2 11 6 0 7 2 5 8 2 4;}
@font-face
{font-family:"\@MS PGothic";}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:12.0pt;
font-family:"MS PGothic",sans-serif;
mso-fareast-language:JA;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US'>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$B!G(Bm not convinced that is a goal that we should undertake <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>From:</span></b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> Openid-specs-ab <openid-specs-ab-bounces@lists.openid.net> <b>On Behalf Of </b>Kristina Yasuda via Openid-specs-ab<br><b>Sent:</b> Tuesday, February 2, 2021 3:41 AM<br><b>To:</b> Artifact Binding/Connect Working Group <openid-specs-ab@lists.openid.net><br><b>Cc:</b> Kristina Yasuda <Kristina.Yasuda@microsoft.com><br><b>Subject:</b> [Openid-specs-ab] Comments on Aggregated Claims/Credential Provider documents<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal><span style='font-family:"Calibri",sans-serif;color:black'>Hi, <o:p></o:p></span></p></div><div><div><p class=MsoNormal><span style='font-family:"Calibri",sans-serif;color:black;background:white'>Below are comments/questions</span><span style='font-family:"Calibri",sans-serif;color:black'> after reading <a href="https://bitbucket.org/openid/connect/src/00140ab1e32c7160ed2635ce871c555ce7c32b75/openid-connect-claims-aggregation/openid-connect-claims-aggregation-1_0.md" title="https://bitbucket.org/openid/connect/src/00140ab1e32c7160ed2635ce871c555ce7c32b75/openid-connect-claims-aggregation/openid-connect-claims-aggregation-1_0.md">Aggregated Claims</a> and <a href="https://mattrglobal.github.io/oidc-client-bound-assertions-spec/#name-token-endpoint-response" title="https://mattrglobal.github.io/oidc-client-bound-assertions-spec/#name-token-endpoint-response">Credential Provider</a> drafts as requested during today's Connect call:<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-family:"Calibri",sans-serif;color:black'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-family:"Calibri",sans-serif;color:black'>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$B!G(Bs 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. <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-family:"Calibri",sans-serif;color:black'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-family:"Calibri",sans-serif;color:black'>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? <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-family:"Calibri",sans-serif;color:black'><o:p> </o:p></span></p></div><div><p class=MsoNormal><span style='font-family:"Calibri",sans-serif;color:black'>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 <span style='background:white'>Aggregated Claims document</span>.<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-family:"Calibri",sans-serif;color:black'><br><br><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-family:"Calibri",sans-serif;color:black'>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!).<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-family:"Calibri",sans-serif;color:black'><br><br><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-family:"Calibri",sans-serif;color:black'>Best Regards,<o:p></o:p></span></p></div><p class=MsoNormal><span style='font-family:"Calibri",sans-serif;color:black'>Kristina<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-family:"Calibri",sans-serif;color:black'><o:p> </o:p></span></p></div><div class=MsoNormal align=center style='text-align:center'><hr size=2 width="98%" align=center></div><div id=divRplyFwdMsg><p class=MsoNormal><b><span lang=JA style='font-size:11.0pt;color:black'>$B:9=P?M(B</span></b><b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>:</span></b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'> Openid-specs-ab <<a href="mailto:openid-specs-ab-bounces@lists.openid.net">openid-specs-ab-bounces@lists.openid.net</a>> </span><span lang=JA style='font-size:11.0pt;color:black'>$B$,(B</span><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'> Takahiko Kawasaki via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>> </span><span lang=JA style='font-size:11.0pt;color:black'>$B$NBeM}$GAw?.(B</span><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'><br></span><b><span lang=JA style='font-size:11.0pt;color:black'>$BAw?.F|;~(B</span></b><b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>:</span></b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'> 2020</span><span lang=JA style='font-size:11.0pt;color:black'>$BG/(B</span><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>11</span><span lang=JA style='font-size:11.0pt;color:black'>$B7n(B</span><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>17</span><span lang=JA style='font-size:11.0pt;color:black'>$BF|(B</span><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'> 6:09<br></span><b><span lang=JA style='font-size:11.0pt;color:black'>$B08@h(B</span></b><b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>:</span></b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'> Artifact Binding/Connect Working Group <<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>><br><b>CC:</b> Takahiko Kawasaki <<a href="mailto:taka@authlete.com">taka@authlete.com</a>><br></span><b><span lang=JA style='font-size:11.0pt;color:black'>$B7oL>(B</span></b><b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'>:</span></b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:black'> [Openid-specs-ab] Feedback to OpenID Connect Claims Aggregation 1.0</span> <o:p></o:p></p><div><p class=MsoNormal> <o:p></o:p></p></div></div><div><div><p class=MsoNormal>Hello,<br><br>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. <o:p></o:p></p><div><p class=MsoNormal><br>- - - - - - - - - -<br><br>- 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.<br><br>- 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.<br><br>- 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.<br><br>- 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.<br><br>- "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.<br><br>- 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.<br><br>Editorial Issues<br>- "http" is used in some links.<br>- Link to RFC 7636 is wrong.<br>- Links to JW* specifications are old. They should point to IETF RFCs.<br>- Link to MTLS is old. It should point to the IETF RFC 8705.<br>- Referenced OpenID.IDA specification is not the latest one. The published latest version is ID2.<br>- The list in Section 1 is not properly formatted in HTML.<br>- Parameter names should be monospace instead of italic.<br>- Section 5.4: s/Code Authorization Flow/Authorization Code Flow/<br>- Section 5.6.1: JSON object given to "aud" in the Aggregation Request is wrong.<br>- Section 5.6.2: s/MAY elect to/MAY select to/<br>- More diagrams and examples are needed for readers.<br><br>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?<br><br>Best Regards,<br>Takahiko Kawasaki<o:p></o:p></p></div></div></div></div></body></html>