[Openid-specs-ab] Feedback on latest drafts

[Nat Sakimura]

Thanks Chuck.

Comments inline:

On Tue, Jul 19, 2011 at 3:38 AM, Chuck Mortimore
<cmortimore at salesforce.com>wrote:

>  Sorry I’ve been checked out for a bit.  Swamped at work and just catching
> up.   Feedback on the latest drafts:
>
> General: I know it’s well understood, but I’ll re-iterate that the current
> document organization is extremely hard to follow.    I’d prefer one
> document for core/minimal, and additional documents for disco, registration,
> and session that layer on top.   I’d also consider moving the request file
> method to a separate doc.  In that light, I don’t understand the existence
> of  “framework” at all.
>

We are fully aware of the problems of the current document organization. We
are going to fix it in a few weeks time.
Generally, we will put a spot light on the Basic HTTP Binding and call it
either "OpenID Connect" or "OpenID Connect Basic" or something.
That will be the document that a developer who wants to do twitter like
simple thing should read.

Whether to have "request" and "request_url" parameters in it is a point to
debate. I suppose it could be moved to "OpenID Connect Professional" etc.
spec. Appropriately renamed version of the framework spec will be referenced
from there.


>
> General: Let’s add some language on when/why to choose the various request
> methods.
>

Good idea.


>
> http-redirect 3.1.1:  would like to see display=touch.   There is precedent
> for this in at least the salesforce and facebook implementations, as well as
> the draft submission david put out awhile back
>

Seems to be a good idea, too.


>
> http-redirect 3.1.1:  The overlap between prompt, pape, and max_auth_age in
> the id_token is confusing.   I like the simplicity of prompt, but need the
> flexability of max_auth_age
>

Do you have a text suggestion?


>
> http-redirect 3.1.1:  id_token_audience is never really defined
>

Need to fix.


>
> http-redirect 3.1.1:  select_ account seems references “the account in the
> request” but I can’t find any means of specifying an account in a request
>
>
Need to add text.


> http-redirect 3.1.5:  I don’t think we should be defining secret_type in
> this spec.  I’d rather see this inherit from the assertion work in core
> oauth.
>

That's actually marked as TODO right below it.
We need to fix it.
Mike, do you have any preference or text?


>
> http-redirect 3.1.1: It’s not clear the difference between the query
> parameters method and the request parameter method.   Are all the values
> from the request parameter supposed to be serializable as query params, or
> is this just the simplest possible request and hence the request param can
> be eliminated?
>

When using "request" parameter, query parameter is just there to be OAuth
2.0 compliant. You just make the simplest possible query parameters just to
be compliant. We probably need clarification text.


>
> session: we don’t ever stop to explain what an id_token is in relation to
> an access_token and why/when you’d want to use one.   Should be covered in
> terminology.
>

Points taken.


>
> http-redirect general: If we want a minimal flow, and then layered
> documents like session, there are some odd dependencies between the two.
>   Http-redirect references and uses id_tokens without any explanation.  Only
> when you get to session do you really get some info on what they are.
>

id token is there not only for session management. We need text to explain
what it really is in the Http-redirect.


>
> -cmort
>
>
>
> _______________________________________________
> 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/20110719/bb5358ef/attachment.html>