<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-15">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi all,<br>
<br>
please find below some questions, thoughts and comments regarding
the current Connect specs:<br>
<a href="http://openid.net/specs/openid-connect-messages-1_0.html"></a><br>
<a href="http://openid.net/specs/openid-connect-messages-1_0.html">http://openid.net/specs/openid-connect-messages-1_0.html</a><br>
<br>
scope/response type: what is the expected usage of response type
"id_token" and scope "openid"? Is it possible to just request an
access token for the user info endpoint w/o getting an id_token? Im
asking because the spec states: "<span class="Apple-style-span"
style="color: rgb(0, 0, 0); font-family: verdana, charcoal,
helvetica, arial, sans-serif; font-style: normal; font-variant:
normal; font-weight: normal; letter-spacing: normal; line-height:
normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px;
text-transform: none; white-space: normal; widows: 2;
word-spacing: 0px; -webkit-text-size-adjust: auto;
-webkit-text-stroke-width: 0px; background-color: rgb(255, 255,
255); font-size: small; display: inline !important; float: none; ">The<span
class="Apple-converted-space"> </span></span><tt style="color:
rgb(0, 51, 102); font-family: 'Courier New', Courier, monospace;
font-size: small; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal; line-height: normal;
orphans: 2; text-align: -webkit-auto; text-indent: 0px;
text-transform: none; white-space: normal; widows: 2;
word-spacing: 0px; -webkit-text-size-adjust: auto;
-webkit-text-stroke-width: 0px; background-color: rgb(255, 255,
255); ">openid</tt><span class="Apple-style-span" style="color:
rgb(0, 0, 0); font-family: verdana, charcoal, helvetica, arial,
sans-serif; font-style: normal; font-variant: normal; font-weight:
normal; letter-spacing: normal; line-height: normal; orphans: 2;
text-align: -webkit-auto; text-indent: 0px; text-transform: none;
white-space: normal; widows: 2; word-spacing: 0px;
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;
background-color: rgb(255, 255, 255); font-size: small; display:
inline !important; float: none; "><span
class="Apple-converted-space"> </span>value also requests that
the ID Token associated with the authentication session be
returned.</span>" Does this mean the id_token is always returned
if the client requests the openid scope?<br>
<br>
User attributes: As far as I understand the spec, the scope value
"openid" always requests access to user attributes via User Info.
The set of attributes is determined by OP and/or user. The scope
values "profile", "address", and "email" just further qualify the
user attributes requested by the client. Is this correct? Does
profile really only refer to the profile URL? This would also mean a
client interested in obtaining the user's name or nickname would
need to use the JSON request object. Is this the idea? <br>
<br>
What is the minimal set of user attributes allowed on the user info
endpoint? I could imagine some OPs only disclose user identifier.<br>
<br>
Did you consider to enclose the OpenId Connect scopes into a
namespace? The current naming may cause name clashes.<br>
<br>
<span class="Apple-style-span" style="color: rgb(0, 0, 0);
font-family: verdana,charcoal,helvetica,arial,sans-serif;
font-style: normal; font-variant: normal; font-weight: normal;
letter-spacing: normal; line-height: normal; orphans: 2;
text-indent: 0px; text-transform: none; white-space: normal;
widows: 2; word-spacing: 0px; background-color: rgb(255, 255,
255); font-size: small; display: inline ! important; float: none;">nonce:
what kind of replay attacks shall this parameter prevent?<br>
<br>
display: In my opinion, display="none" would better fit into the
list of values of the prompt parameter.<br>
<br>
We already discussed the inclusion of OAuth request parameters in
the JSON request object. I would suggest to only include Connect
parameters in this object as long as there is no OAuth JSON
Request binding.<br>
<br>
§3.2.1 Access Token Request <br>
<br>
client_secret: Why is this parameter made REQUIRED? The OAuth spec
allows for unauthenticated requests.<br>
code/refresh token: Why are both parameters REQUIRED? I assume
those are alternative because the belong to different gran types.<br>
<br>
§3.2.2.<br>
<br>
"</span><span class="Apple-style-span" style="color: rgb(0, 0, 0);
font-family: verdana,charcoal,helvetica,arial,sans-serif;
font-style: normal; font-variant: normal; font-weight: normal;
letter-spacing: normal; line-height: normal; orphans: 2;
text-indent: 0px; text-transform: none; white-space: normal;
widows: 2; word-spacing: 0px; background-color: rgb(255, 255,
255); font-size: small; display: inline ! important; float: none;">After
receiving and verifying a valid and authorized Access Token
Request from the client, the Authorization Server returns a
Positive Assertion that includes an Access Token and an ID Token."<br>
<br>
I assume the id_token is only returned in case the client request
it explicitely using response type "id_token"?<br>
<br>
§3.3.2<br>
<br>
"</span><span class="Apple-style-span" style="color: rgb(0, 0, 0);
font-family: verdana,charcoal,helvetica,arial,sans-serif;
font-style: normal; font-variant: normal; font-weight: normal;
letter-spacing: normal; line-height: normal; orphans: 2;
text-indent: 0px; text-transform: none; white-space: normal;
widows: 2; word-spacing: 0px; background-color: rgb(255, 255,
255); font-size: small; display: inline ! important; float: none;">If
the requested schema is "openid", the response MUST return a JSON
object that contains the full set or subset of claims that are
defined below."<br>
<br>
I assume the set of claims is determined by the scope(s)
associated with the access token?<br>
<br>
</span><a
href="http://openid.net/specs/openid-connect-standard-1_0.html">http://openid.net/specs/openid-connect-standard-1_0.html</a><br>
What is the reason for having this and the messages document since
all bindings are explained in one document? In the current
structure, there seems to be some redundancy between the documents.<br>
<br>
What is the purpose of the response type "<span
class="Apple-style-span" style="color: rgb(0, 0, 0); font-family:
verdana, charcoal, helvetica, arial, sans-serif; font-style:
normal; font-variant: normal; font-weight: normal; letter-spacing:
normal; line-height: normal; orphans: 2; text-align: -webkit-auto;
text-indent: 0px; text-transform: none; white-space: normal;
widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto;
-webkit-text-stroke-width: 0px; background-color: rgb(255, 255,
255); font-size: small; display: inline !important; float: none; ">code
token</span>"?<br>
<br>
§4.3.1.3.3. Authorization Server Fetches the Request File<br>
<br>
"<span class="Apple-style-span" style="color: rgb(0, 0, 0);
font-family: verdana, charcoal, helvetica, arial, sans-serif;
font-style: normal; font-variant: normal; font-weight: normal;
letter-spacing: normal; line-height: normal; orphans: 2;
text-align: -webkit-auto; text-indent: 0px; text-transform: none;
white-space: normal; widows: 2; word-spacing: 0px;
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;
background-color: rgb(255, 255, 255); font-size: small; display:
inline !important; float: none; ">Upon receipt of the Request, the
Authorization Server MUST send a GET request to the<span
class="Apple-converted-space"> </span></span><tt style="color:
rgb(0, 51, 102); font-family: 'Courier New', Courier, monospace;
font-size: small; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal; line-height: normal;
orphans: 2; text-align: -webkit-auto; text-indent: 0px;
text-transform: none; white-space: normal; widows: 2;
word-spacing: 0px; -webkit-text-size-adjust: auto;
-webkit-text-stroke-width: 0px; background-color: rgb(255, 255,
255); ">request_uri</tt><span class="Apple-style-span"
style="color: rgb(0, 0, 0); font-family:
verdana,charcoal,helvetica,arial,sans-serif; font-style: normal;
font-variant: normal; font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: 2; text-indent: 0px; text-transform:
none; white-space: normal; widows: 2; word-spacing: 0px;
background-color: rgb(255, 255, 255); font-size: small; display:
inline ! important; float: none;"><span
class="Apple-converted-space"> </span>to retrieve the content
unless it is already cached and parse it to recreate the
authorization request parameters.<br>
<br>
</span><span class="Apple-style-span" style="color: rgb(0, 0, 0);
font-family: verdana, charcoal, helvetica, arial, sans-serif;
font-style: normal; font-variant: normal; font-weight: normal;
letter-spacing: normal; line-height: normal; orphans: 2;
text-align: -webkit-auto; text-indent: 0px; text-transform: none;
white-space: normal; widows: 2; word-spacing: 0px;
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;
background-color: rgb(255, 255, 255); font-size: small; display:
inline !important; float: none; ">Note that the RP SHOULD use a
unique URI for each request, or otherwise prevent the
Authorization server from caching the<span
class="Apple-converted-space"> </span></span><tt style="color:
rgb(0, 51, 102); font-family: 'Courier New', Courier, monospace;
font-size: small; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal; line-height: normal;
orphans: 2; text-align: -webkit-auto; text-indent: 0px;
text-transform: none; white-space: normal; widows: 2;
word-spacing: 0px; -webkit-text-size-adjust: auto;
-webkit-text-stroke-width: 0px; background-color: rgb(255, 255,
255); ">request_uri</tt><span class="Apple-style-span"
style="color: rgb(0, 0, 0); font-family: verdana, charcoal,
helvetica, arial, sans-serif; font-style: normal; font-variant:
normal; font-weight: normal; letter-spacing: normal; line-height:
normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px;
text-transform: none; white-space: normal; widows: 2;
word-spacing: 0px; -webkit-text-size-adjust: auto;
-webkit-text-stroke-width: 0px; background-color: rgb(255, 255,
255); font-size: small; display: inline !important; float: none; ">.</span>"<br>
<span class="Apple-style-span" style="color: rgb(0, 0, 0);
font-family: verdana,charcoal,helvetica,arial,sans-serif;
font-style: normal; font-variant: normal; font-weight: normal;
letter-spacing: normal; line-height: normal; orphans: 2;
text-indent: 0px; text-transform: none; white-space: normal;
widows: 2; word-spacing: 0px; background-color: rgb(255, 255,
255); font-size: small; display: inline ! important; float: none;"><br>
I'm a bit confused. Is caching of the request object desirable or
must be prevented? I think it must be prevented because otherwise
the client cannot send different state parameter values, which are
required for XSRF prevention.<br>
<br>
§5.2. Refreshing an Access Token<br>
"Authorization servers MUST support both forms of client
authentication at the Token Endpoint."<br>
<br>
What is meant by this statement? BASIC and body parameters or
client secret and JWT? <br>
<br>
$5.2.1. Positive Assertion<br>
When is the authorization server expected to return an id_token? I
assume if the original authorization request's response type
parameter contained "id_token"? Is this refreshed id_token
expected to have a connection to a SSO session? Could make things
complicated.<br>
<br>
7. Check ID Endpoint<br>
I don't understand why the id_token format must be defined if the
client is supposed to use another endpoint to obtain the data
contained. In my opinionn, either the id_token is an assertion and
can directly be interpreted by the client or it is an access token
(as other OAuth access tokens) and can be used to obtain user
session data from a session endpoint. Why not making this two
different OpenId connect modes?<br>
<br>
Same holds for the session management. If the id_token is used to
prolong or terminate sessions, the client does not need to
interpret its containt.<br>
<br>
Thoughts?<br>
<br>
</span><a
href="http://openid.net/specs/openid-connect-session-1_0.html">http://openid.net/specs/openid-connect-session-1_0.html</a><br>
<span class="Apple-style-span" style="color: rgb(0, 0, 0);
font-family: verdana,charcoal,helvetica,arial,sans-serif;
font-style: normal; font-variant: normal; font-weight: normal;
letter-spacing: normal; line-height: normal; orphans: 2;
text-indent: 0px; text-transform: none; white-space: normal;
widows: 2; word-spacing: 0px; background-color: rgb(255, 255,
255); font-size: small; display: inline ! important; float: none;">3.1.4.
Implicit (User-Agent) Flow<br>
"The user-agent and client servlet can then use the session
management endpoints by presenting the ID token to the endpoints."<br>
<br>
What is the client servlet and which role does it play? There seem
to be underlying ideas about how clients should use Connect and
their architecture. Could you please describe them? <br>
<br>
</span><a
href="http://openid.net/specs/openid-connect-basic-1_0.html">http://openid.net/specs/openid-connect-basic-1_0.html</a><br>
"The OpenID Connect Basic Client profile only documents clients
using the implicit flow."<br>
<br>
Does this mean Connect Basic is suited for JavaScript clients only?
I'm asking because standard web application cannot access the URL
fragment used to pass the tokens back to the user agent.<br>
<br>
How are such clients supposed to access the user info and check id
endpoints given the same-origin policy? Or does Connect rely on
CORS?<br>
<span class="Apple-style-span" style="color: rgb(0, 0, 0);
font-family: verdana, charcoal, helvetica, arial, sans-serif;
font-style: normal; font-variant: normal; font-weight: normal;
letter-spacing: normal; line-height: normal; orphans: 2;
text-align: -webkit-auto; text-indent: 0px; text-transform: none;
white-space: normal; widows: 2; word-spacing: 0px;
-webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;
background-color: rgb(255, 255, 255); font-size: small; display:
inline !important; float: none; "><br>
regards,<br>
Torsten.<br>
</span>
</body>
</html>