[Openid-specs-ab] Some comments

Sun Nov 6 18:20:35 UTC 2011

Hi all,

please find below some questions, thoughts and comments regarding the 
current Connect specs:
<http://openid.net/specs/openid-connect-messages-1_0.html>
http://openid.net/specs/openid-connect-messages-1_0.html

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: "Theopenidvalue also requests that the ID Token 
associated with the authentication session be returned." Does this mean 
the id_token is always returned if the client requests the openid scope?

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?

What is the minimal set of user attributes allowed on the user info 
endpoint? I could imagine some OPs only disclose user identifier.

Did you consider to enclose the OpenId Connect scopes into a namespace? 
The current naming may cause name clashes.

nonce: what kind of replay attacks shall this parameter prevent?

display: In my opinion, display="none" would better fit into the list of 
values of the prompt parameter.

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.

§3.2.1 Access Token Request

client_secret: Why is this parameter made REQUIRED? The OAuth spec 
allows for unauthenticated requests.
code/refresh token: Why are both parameters REQUIRED? I assume those are 
alternative because the belong to different gran types.

§3.2.2.

"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."

I assume the id_token is only returned in case the client request it 
explicitely using response type "id_token"?

§3.3.2

"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."

I assume the set of claims is determined by the scope(s) associated with 
the access token?

http://openid.net/specs/openid-connect-standard-1_0.html
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.

What is the purpose of the response type "code token"?

§4.3.1.3.3.  Authorization Server Fetches the Request File

"Upon receipt of the Request, the Authorization Server MUST send a GET 
request to therequest_urito retrieve the content unless it is already 
cached and parse it to recreate the authorization request parameters.

Note that the RP SHOULD use a unique URI for each request, or otherwise 
prevent the Authorization server from caching therequest_uri."

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.

§5.2.  Refreshing an Access Token
"Authorization servers MUST support both forms of client authentication 
at the Token Endpoint."

What is meant by this statement? BASIC and body parameters or client 
secret and JWT?

$5.2.1.  Positive Assertion
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.

7.  Check ID Endpoint
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?

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.

Thoughts?

http://openid.net/specs/openid-connect-session-1_0.html
3.1.4.  Implicit (User-Agent) Flow
"The user-agent and client servlet can then use the session management 
endpoints by presenting the ID token to the endpoints."

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?

http://openid.net/specs/openid-connect-basic-1_0.html
"The OpenID Connect Basic Client profile only documents clients using 
the implicit flow."

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.

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?

regards,
Torsten.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20111106/ea331dbc/attachment.html>