[Openid-specs-ab] Some more feedback on spec drafts

[Mike Jones]

Are you going to be able to be at the IETF meeting in Quebec next week?  We're going to be working on the document restructuring there.

				-- Mike

-----Original Message-----
From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Breno de Medeiros
Sent: Tuesday, July 19, 2011 8:59 AM
To: openid-specs-ab at lists.openid.net
Subject: [Openid-specs-ab] Some more feedback on spec drafts

I had some time during a flight yesterday to read the documentation on HTTP binding as well as UserInfo (didn't get to Session Management -- I think I will try my hand at a full re-write of that document once the HTTP binding is more stable). I jotted down my thoughts

Here is the document I created:
https://docs.google.com/document/d/1qKGUUwhEiFuxe9QtFqc28vk1FObuXSw4NtKbyCSSMuY/edit?hl=en_US

Contents attached here for feedback:

HTTP Redirect Binding


Definitions


1. The HTTP Redirect Binding should make no references to the core, including to the term definitions section

2. In particular, the following definitions from Core (that are relevant to extend and framework, but not to minimal) should not be provided in order to read the minimum:

- Claims, Claims Provider, OpenID Request Object
- OpenID provider should be renamed identity provider
- Questionable: Assertion, Entity, ID Token
- Credential is not defined
- Direct and Indirect communication are not defined

3. In the spec itself, the following definitions should be removed

- Artifact
- Request URI
- Request Registration Endpoint
- Request File

Overview


Should indicate the fact that the two flows can be used in combination when a client consists of different components that both maintain user signed-in state

Protocol Flows


The fact that indirect communication is not defined results in that the protocol description in flows is subtly incorrect.

- Client sends a request to authorization server -> Client submits the request to the User-Agent which forwards it to the authorization server. For instance, the client may issue a 302 Http response to the User-Agent with a Location header pointing to the authorization server's authorization endpoint with the request formatted as query parameters of the Http Request. Or the client may set the location.href property in a user agents' child frame or window, if the User-Agent is full HTML4 or 5 compliant client.
- User Agent submits the client-generated request to the authorization server
- Authorization Server authenticates the user via credentials submitted by the User-Agent by means that are outside the scope of this specification
- Authorization Server validates that the user has properly authorized the request or interacts with the user to obtain such authorization, by means that are outside the scope of this specification.
-  Authorization Server generates a response and submits it to the User-Agent for forwarding it to the client. For instance, the server may issue an 302 HTTP redirect response to the User-Agent with a Location Header pointing to the client's redirect URI and with response parameters encoded as query (code flow) or fragment (token,
code+token flow) parameters.  Or the server may set location.href
property.

[Things that could also happen, but I am not sure whether we want to include this in the spec: Or the server may issue an HTML5-compliant cross-domain postMessage command with the JSON-encoded response. Or (if the response_type is 'none'), the Server may simply record the grant, and simply return the user to the client via an HTTP redirect or through history navigation.]

- Client processes the response in a flow-specific manner.

Suggestion: Rename id_token_audience to audience

Suggestion: Do not document the request and request_uri objects here
-- they are part of framework or messages

- There is precious little discussion of display values and prompt values. There is no discussion about the requirement to support implicit authorization (i.e., immediate mode).

I recommend that the discussion discuss code and 'code + token' in parallel, with token being understood as being equal to 'code+token'
with the code processing parts being ommited.

- There is no discussion of the token introspection endpoint. Id_token is assumed. The opposite of what was agreed.

- The JWT format is mandated here, while there was agreement to leave it to framework/messages

UserInfo


- UserInfo should not make reference to Core definitions, only to OAuth2



--
--Breno
_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs-ab