[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