<br><br><div class="gmail_quote">On Wed, Jul 20, 2011 at 12:59 AM, Breno de Medeiros <span dir="ltr"><<a href="mailto:breno@google.com">breno@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I had some time during a flight yesterday to read the documentation on<br>
HTTP binding as well as UserInfo (didn't get to Session Management --<br>
I think I will try my hand at a full re-write of that document once<br>
the HTTP binding is more stable). I jotted down my thoughts<br>
<br>
Here is the document I created:<br>
<a href="https://docs.google.com/document/d/1qKGUUwhEiFuxe9QtFqc28vk1FObuXSw4NtKbyCSSMuY/edit?hl=en_US" target="_blank">https://docs.google.com/document/d/1qKGUUwhEiFuxe9QtFqc28vk1FObuXSw4NtKbyCSSMuY/edit?hl=en_US</a><br>
<br>
Contents attached here for feedback:<br>
<br>
HTTP Redirect Binding<br>
<br>
<br>
Definitions<br>
<br>
<br>
1. The HTTP Redirect Binding should make no references to the core,<br>
including to the term definitions section<br></blockquote><div><br></div><div>Accept. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
2. In particular, the following definitions from Core (that are<br>
relevant to extend and framework, but not to minimal) should not be<br>
provided in order to read the minimum:<br>
<br>
- Claims, Claims Provider, OpenID Request Object<br>
- OpenID provider should be renamed identity provider<br>
- Questionable: Assertion, Entity, ID Token<br>
- Credential is not defined<br>
- Direct and Indirect communication are not defined<br></blockquote><div><br></div><div>Accept. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
3. In the spec itself, the following definitions should be removed<br>
<br>
- Artifact<br>
- Request URI<br>
- Request Registration Endpoint<br>
- Request File<br>
<br></blockquote><div><br></div><div>Accept. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Overview<br>
<br>
<br>
Should indicate the fact that the two flows can be used in combination<br>
when a client consists of different components that both maintain user<br>
signed-in state<br></blockquote><div><br></div><div>Accept in principle: Is there a text that states this in OAuth 2.0? If so, please point me there. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Protocol Flows<br>
<br>
<br>
The fact that indirect communication is not defined results in that<br>
the protocol description in flows is subtly incorrect.<br></blockquote><div><br></div><div>Accept: Indirect Communication defined. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
- Client sends a request to authorization server -> Client submits the<br>
request to the User-Agent which forwards it to the authorization<br>
server. For instance, the client may issue a 302 Http response to the<br>
User-Agent with a Location header pointing to the authorization<br>
server’s authorization endpoint with the request formatted as query<br>
parameters of the Http Request. Or the client may set the<br>
location.href property in a user agents’ child frame or window, if the<br>
User-Agent is full HTML4 or 5 compliant client.<br>
- User Agent submits the client-generated request to the authorization server<br>
- Authorization Server authenticates the user via credentials<br>
submitted by the User-Agent by means that are outside the scope of<br>
this specification<br>
- Authorization Server validates that the user has properly authorized<br>
the request or interacts with the user to obtain such authorization,<br>
by means that are outside the scope of this specification.<br>
- Authorization Server generates a response and submits it to the<br>
User-Agent for forwarding it to the client. For instance, the server<br>
may issue an 302 HTTP redirect response to the User-Agent with a<br>
Location Header pointing to the client’s redirect URI and with<br>
response parameters encoded as query (code flow) or fragment (token,<br>
code+token flow) parameters. Or the server may set location.href<br>
property.<br>
<br>
[Things that could also happen, but I am not sure whether we want to<br>
include this in the spec: Or the server may issue an HTML5-compliant<br>
cross-domain postMessage command with the JSON-encoded response. Or<br>
(if the response_type is ‘none’), the Server may simply record the<br>
grant, and simply return the user to the client via an HTTP redirect<br>
or through history navigation.]<br>
<br></blockquote><div><br></div><div>Discuss: Do we need to enumerate those various methods? </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
- Client processes the response in a flow-specific manner.<br>
<br>
Suggestion: Rename id_token_audience to audience<br></blockquote><div><br></div><div>Accept. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Suggestion: Do not document the request and request_uri objects here<br>
-- they are part of framework or messages<br>
<br></blockquote><div><br></div><div>Accept. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
- There is precious little discussion of display values and prompt<br>
values. There is no discussion about the requirement to support<br>
implicit authorization (i.e., immediate mode).<br></blockquote><div><br></div><div>Accept in principle: Text suggestion welcome. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
I recommend that the discussion discuss code and ‘code + token’ in<br>
parallel, with token being understood as being equal to ‘code+token’<br>
with the code processing parts being ommited.<br></blockquote><div><br></div><div>Discuss: Does OAuth 2.0 allow it? </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
- There is no discussion of the token introspection endpoint. Id_token<br>
is assumed. The opposite of what was agreed.<br></blockquote><div><br></div><div>Accept. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
- The JWT format is mandated here, while there was agreement to leave<br>
it to framework/messages<br>
<br></blockquote><div><br></div><div>Accept. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
UserInfo<br>
<br>
<br>
- UserInfo should not make reference to Core definitions, only to OAuth2<br>
<font color="#888888"><br></font></blockquote><div><br></div><div>Accept in principle: UserInfo for the Lite version is included in the Lite. </div><div>UserInfo itself may be incorporated into Messages. </div><div><br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><font color="#888888">
<br>
<br>
--<br>
--Breno<br>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Nat Sakimura (=nat)<div>Chairman, OpenID Foundation<br><a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>@_nat_en</div><br>