[Openid-specs-ab] Two questions for you, Breno

Breno de Medeiros breno at google.com
Fri Jul 29 16:10:09 UTC 2011


On Fri, Jul 29, 2011 at 08:45, John Bradley <ve7jtb at ve7jtb.com> wrote:
> Thinking about it,  I think specifying audience in the request for the lite
> spec is not useful.
> From a RP inspecting a response as a result of a "token" flow they should
> expect to find their client_id and redirect_uri as the audience.
> Is there a argument to tell them to only compare the audience to their
> redirect_uri.   It may be required for the advanced flow that I think Breno
> is anticipating where a smart client gets a token but is under some policy
> allowed to specify a 4th party as the audience.

My proposal is that RP can drop audience in the request if it equals
the client_id.  However, the token will have 'audience' and
'issued_to', where the latter is optional.

I don't see the value of adding the redirect_uri to the token. It will
make the token too large.

> So in lite for a RP using the Token flow I want to drop audience from the
> request and only have them compare audience to there redirect_uri  that
> should leave the door open in full to the more complicated options.
> John
>
> On 2011-07-28, at 11:02 PM, John Bradley wrote:
>
> I sort of get what you are doing.
> I think that you are thinking of the primary audience being the client_id
> and the audience as bing a web site the client presents the token at.
> That is a bit of a twist on what we were thinking of audience for.  I need
> to sleep on it.
> It of makes sense if you look at it as a smart client/selector.   It may be
> too complicated to explain fully in the lite spec.
> John
> On 2011-07-28, at 7:00 PM, Mike Jones wrote:
>
> Breno, two questions came up on the call that we need you to provide your
> input on.
>
> 1.  Having a requested audience parameter seems like a security flaw, as you
> could request a token scoped to someone else.  Shouldn’t we just have the
> audience be the return_to URL or something derived from it?  We plan to
> delete this parameter unless we hear back from you with a good reason why it
> must be kept and why it can be secure.
>
> 2.  Why do we need a nonce parameter when we already have the OAuth state
> parameter to serve this purpose?  Or is it just to be able to provide the
> additional semantics that the value is returned in the id_token?
>
>                                                             Thanks,
>                                                             -- Mike
>
> From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net] On
> Behalf Of Mike Jones
> Sent: Thursday, July 28, 2011 3:53 PM
> To: openid-specs-ab at lists.openid.net
> Subject: [Openid-specs-ab] Spec call notes 28-Jul-11
>
> Spec call notes 28-Jul-11
>
> Mike Jones
> John Bradley
> Edmund Jay
> Nat Sakimura
> Johnny Bufu
>
> Agenda:
>                Specific questions about spec features
>                               audience parameter in request
>                               nonce parameter in request
>                               req -> request in OAuth request
>                               Can a redirect_url be a redirect URI?
>                Editing updates
>                IPR Contribution Agreements
>
> audience parameter in request
>                A bad RP could put in someone else's audience
>                Do we not pass it and have audience constructed out of
> return_to?
>                Edmund thought this had to do with input from Breno about
> native clients
>                We don't have enough information to use it properly - will
> remove unless clarified
>
> nonce parameter in request
>                Should RP supply a nonce or just request that a nonce be
> used?
>                John asked what the difference between nonce and state is
>                Edmund thought that this was something specific to Facebook
>                Nat pointed out that we haven't said anything about
> processing rules for the nonce
>                               Other than that the value is returned in
> id_token
>                               No rule about verifying nonce, at present
>                John will look at the Facebook documentation and investigate
> their usage
>                If not required for the Lite spec, it should probably be
> removed there
>
> req -> request in OAuth HTTP request
>                We agreed to make this change
>
> Can a redirect_url be a redirect URI?
>                We think no
>                This is separate from the js_origin_url
>                               (The js_origin_url may not use an http scheme,
> but is still a redirect target)
>                Nat wondered whether he wanted to change the name just to be
> closer to OAuth
>
> Editing updates
>                Mike has reviewed Casper's edits and is ready to check them
> in, modulo the discussions above
>                John has the Lite spec down to about 15 pages including
> Security Considerations
>                               This includes id_token
>                               Without security considerations and references
> is 10 pages, including 1.5 pages of index
>                               Or roughly 8 pages of spec material
>                John reverted the text to use the name "Introspection
> Endpoint"
>                John asked whether we should copy the relevant portions of
> the Discovery spec into Lite
>                               We agreed no, saying that Discovery is
> optional and could be replaced by manual configuration
>
>                Besides producing Lite, we also need to produce:
>                               Standard
>                               Messages (Core and Framework)
>                Already have:
>                               Discovery
>                               Registration
>                               Session Management
>
>                Lite is pared down to the world view of an RP
>                               Compliance for IdPs may be different for IdPs
> than for RPs
>                               IdPs should support code and token flows but
> RPs can just support token
>                               Say this in a conformance section in Standard
>
> IPR Contribution Agreements
>                Nat will review the list archives and produce a list of
> people we need IPR agreements from
>                We should not go to an implementer's draft until we have the
> appropriate agreements in place
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>



-- 
--Breno


More information about the Openid-specs-ab mailing list