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

[Nat Sakimura]

On Wed, Jul 20, 2011 at 12:59 AM, Breno de Medeiros <breno at google.com>wrote:

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

Accept.


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

Accept.


>
> 3. In the spec itself, the following definitions should be removed
>
> - Artifact
> - Request URI
> - Request Registration Endpoint
> - Request File
>
>
Accept.


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

Accept in principle: Is there a text that states this in OAuth 2.0? If so,
please point me there.


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

Accept: Indirect Communication defined.


>
> - 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.]
>
>
Discuss: Do we need to enumerate those various methods?


> - Client processes the response in a flow-specific manner.
>
> Suggestion: Rename id_token_audience to audience
>

Accept.


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


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

Accept in principle: Text suggestion welcome.


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

Discuss: Does OAuth 2.0 allow it?


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

Accept.


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


> UserInfo
>
>
> - UserInfo should not make reference to Core definitions, only to OAuth2
>
>
Accept in principle: UserInfo for the Lite version is included in the
 Lite.
UserInfo itself may be incorporated into Messages.


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



-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110723/9404ceae/attachment.html>