<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:x="urn:schemas-microsoft-com:office:excel" 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=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:"Calibri","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@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">
<div class="WordSection1">
<p class="MsoPlainText">Thanks for the detailed review, as always George. This is my Disposition of Comments (DoC) reply to your review. If I accepted your suggestion, I haven't included any reply to it here.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">The changes resulting from this review have been released at
<a href="http://openid.bitbucket.org/">http://openid.bitbucket.org/</a>. Note that this also resulted in clarifications in the Core spec about when signing must be performed before encryption (for ID Tokens) and when encryption can be performed without first
signing (for UserInfo responses and Request Objects) and a clarification that the result of signing followed by encryption is a Nested JWT.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">2-2: This can't be returned as a static value because it may be client-specific.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">4-2: Unless the RP wants a failure, it needs to use an algorithm supported by the OP, which it learned from the “id_token_signing_alg_values_supported” parameter.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">5-4: <a href="http://openid.net/specs/openid-connect-core-1_0.html#ServerMTI">
http://openid.net/specs/openid-connect-core-1_0.html#ServerMTI</a> requires support for Maximum Authentication Age. That being said, all of Registration is optional.<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"> -- Mike<o:p></o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">-----Original Message-----<br>
From: openid-specs-ab-bounces@lists.openid.net [mailto:openid-specs-ab-bounces@lists.openid.net] On Behalf Of George Fletcher<br>
Sent: Saturday, October 26, 2013 7:50 AM<br>
To: openid-specs-ab@lists.openid.net<br>
Subject: [Openid-specs-ab] Openid connect registration review</p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText"><o:p> </o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> See file attached to this message<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> File: OpenID Connect Registration - draft 20 - flattened.pdf<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> Annotation summary:<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> --- Page 2 ---<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> Highlight (yellow), Oct 25, 2013, 11:57 AM, George Fletcher:<o:p></o:p></p>
<p class="MsoPlainText">> co-resident<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> Note (yellow), Oct 25, 2013, 11:57 AM, George Fletcher:<o:p></o:p></p>
<p class="MsoPlainText">> Does co-resident mean the same as the /token API endpoint? Or just on the same server? Overloading the /token endpoint seems like a bad idea.<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> Note (yellow), Oct 25, 2013, 11:57 AM, George Fletcher:<o:p></o:p></p>
<p class="MsoPlainText">> Could (or should) these endpoint also be optionally returned in the openid connect discovery JSON response?<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> Highlight (yellow), Oct 25, 2013, 11:57 AM, George Fletcher:<o:p></o:p></p>
<p class="MsoPlainText">> Client Registration Endpoint<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> Highlight (yellow), Oct 25, 2013, 11:57 AM, George Fletcher:<o:p></o:p></p>
<p class="MsoPlainText">> Client Configuration Endpoint<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> --- Page 4 ---<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> Highlight (yellow), Oct 25, 2013, 11:57 AM, George Fletcher:<o:p></o:p></p>
<p class="MsoPlainText">> Providers that use pairwise sub (subject) values SHOULD provide a sector_identifier_uri.<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> Note (yellow), Oct 25, 2013, 11:57 AM, George Fletcher:<o:p></o:p></p>
<p class="MsoPlainText">> This sentence doesn't make sense to me. I think the point is that providers that support pair wise 'sub' identifiers must support client registered sector_identifier_uri values.<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> Highlight (yellow), Oct 25, 2013, 11:57 AM, George Fletcher:<o:p></o:p></p>
<p class="MsoPlainText">> id_token_signed_response_alg<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> Note (yellow), Oct 25, 2013, 11:57 AM, George Fletcher:<o:p></o:p></p>
<p class="MsoPlainText">> This implies to me that the client gets to dictate what algorithm is going to be used to sign the ID Token. That seems the opposite of all the other cases where the server gets to chose. Is the expected response a registration failure
if the client requests an alg not supported by the AS?<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> --- Page 5 ---<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> Highlight (yellow), Oct 25, 2013, 11:57 AM, George Fletcher:<o:p></o:p></p>
<p class="MsoPlainText">> userinfo_signed_response_alg<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> Note (yellow), Oct 25, 2013, 11:57 AM, George Fletcher:<o:p></o:p></p>
<p class="MsoPlainText">> If this value is not specified, then the default is that user info responses are NOT signed?<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> Highlight (yellow), Oct 25, 2013, 11:57 AM, George Fletcher:<o:p></o:p></p>
<p class="MsoPlainText">> If this is specified the response will be [JWT] serialized, and encrypted using JWE. userinfo_encrypted_response_enc OPTIONAL. JWE enc algorithm REQUIRED for encryption of UserInfo Responses. If userinfo_encrypted_response_alg is
specified the default for this value is A128CBC-HS256. If this is requested in combination with signing the response will be signed then encrypted. If this is specified the response will be [JWT] serialized, and encrypted using JWE. request_object_signing_alg
OPTIONAL. [JWS] alg algorithm that MUST be used for signing Request Objects sent to the Authorization Server. All Request Objects from this client_id MUST be rejected if not signed with this algorithm. Servers SHOULD support RS256. The value none MAY be
used. token_endpoint_auth_method OPTIONAL. Requested authentication method for the Token Endpoint. The options are client_secret_post, client_secret_basic, client_secret_jwt, and private_key_jwt, as described in Section 8 of [OpenID.Core]. Other authentication
methods MAY be defined by extensions. If omitted, the default is client_secret_basic -- the HTTP Basic Authentication Scheme specified in Section 2.3.1 of [RFC6749]. token_endpoint_auth_signing_alg OPTIONAL. [JWS] alg algorithm that MUST be used for signing
the JWT used to authenticate the Client at the Token Endpoint for the private_key_jwt and client_secret_jwt authentication methods. All Token Requests using these authentication methods from this client_id MUST be rejected if the JWT is not signed with this
algorithm. Servers SHOULD support RS256. The value none MUST NOT be used. default_max_age OPTIONAL. Default Maximum Authentication Age. Specifies that the End-User MUST be actively authenticated if the End-User was authenticated longer ago than the specified
number of seconds. The max_age request parameter overrides this default value. require_auth_time OPTIONAL. Boolean value specifying whether the auth_time Claim in the id_token is REQUIRED. It is REQUIRED when the value is true. The auth_time Claim request
in the Request Object overrides this setting. default_acr_values OPTIONAL. Default requested Authentication Context Class Reference values. Array of<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> OpenID Connect Discovery 1.0<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> [JWA]<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> [JWA]<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> JWT<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> [JWA] JWT<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> JWE [JWA]<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> JWT<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> Note (yellow), Oct 25, 2013, 11:57 AM, George Fletcher:<o:p></o:p></p>
<p class="MsoPlainText">> This wording is used many times for these different responses that can be both signed and/or encrypted. I'm wondering if this sentence should include something like....If this option is specified when no signing algorithm is specifed,
then ...<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> Highlight (yellow), Oct 25, 2013, 11:57 AM, George Fletcher:<o:p></o:p></p>
<p class="MsoPlainText">> request_object_signing_alg<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> Note (yellow), Oct 25, 2013, 11:57 AM, George Fletcher:<o:p></o:p></p>
<p class="MsoPlainText">> Do we need to specify a default?<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> Highlight (yellow), Oct 25, 2013, 11:57 AM, George Fletcher:<o:p></o:p></p>
<p class="MsoPlainText">> default_max_age<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> Note (yellow), Oct 25, 2013, 11:57 AM, George Fletcher:<o:p></o:p></p>
<p class="MsoPlainText">> As an OP I'm not sure I want to honor this parameter from a client. I'm assuming that the OP can ignore any parameter from the client it wants and just not return any value for that parameter in the response.<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> --- Page 6 ---<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> Highlight (yellow), Oct 25, 2013, 11:57 AM, George Fletcher:<o:p></o:p></p>
<p class="MsoPlainText">> initiate_login_uri<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> Note (yellow), Oct 25, 2013, 11:57 AM, George Fletcher:<o:p></o:p></p>
<p class="MsoPlainText">> Would a reference to the relevant section of core be useful here? I don't remember this flow very well and this is the first mention of target_link_uri in this document.<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> --- Page 8 ---<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> Highlight (yellow), Oct 25, 2013, 11:57 AM, George Fletcher:<o:p></o:p></p>
<p class="MsoPlainText">> send<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> Note (yellow), Oct 25, 2013, 11:57 AM, George Fletcher:<o:p></o:p></p>
<p class="MsoPlainText">> 'send' should be 'sent'<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> Highlight (yellow), Oct 25, 2013, 11:57 AM, George Fletcher:<o:p></o:p></p>
<p class="MsoPlainText">> HTTP/1.1 200 OK<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> Note (yellow), Oct 25, 2013, 11:57 AM, George Fletcher:<o:p></o:p></p>
<p class="MsoPlainText">> I think this should be a 201 response instead of a 200.<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> --- Page 12 ---<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> Note (yellow), Oct 25, 2013, 11:57 AM, George Fletcher:<o:p></o:p></p>
<p class="MsoPlainText">> It seems like there is some pretty complicated OP logic required to process the sector_identifier_uri. Given that the the list of allowed redirect_uris in the JSON file can change at any time! the OP would need to pull the file and
verify that the current client redirect_uri is still present in the list. That is too much over head to do at token issuance. Should we have some guidance that redirect_uris can be added to the sector_identifier_uri file but SHOULD NOT be removed. Removing
a redirect_uri from the file results in undefined behavior? With this guidance the OP can do all the necessary checking at client registration time which seems reasonable.<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> (report generated by GoodReader)<o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> <o:p></o:p></p>
<p class="MsoPlainText">> --<o:p></o:p></p>
<p class="MsoPlainText">> George Fletcher<o:p></o:p></p>
<p class="MsoPlainText">> Blog: <a href="http://practicalid.blogspot.com"><span style="color:windowtext;text-decoration:none">http://practicalid.blogspot.com</span></a><o:p></o:p></p>
<p class="MsoPlainText">> Photos: <a href="http://www.flickr.com/photos/gffphotos">
<span style="color:windowtext;text-decoration:none">http://www.flickr.com/photos/gffphotos</span></a><o:p></o:p></p>
</div>
</body>
</html>