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

[Breno de Medeiros]

Unfortunately I realized too late that I needed to get my passport
renewed, so I will not be able to travel Internationally until it
arrives.

On Tue, Jul 19, 2011 at 09:28, Mike Jones <Michael.Jones at microsoft.com> wrote:
> 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
>
>



-- 
--Breno