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

Breno de Medeiros breno at google.com
Thu Jul 28 23:51:12 UTC 2011


On Thu, Jul 28, 2011 at 16:00, Mike Jones <Michael.Jones at microsoft.com> 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.

This is intentional. The token would include both the requested
audience and the client_id of the requester.

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

I think the nonce parameter is intended as a simpler mechanism to
provide PAPE binding for re-auth. We can remove it from 'Lite' and
deal with it in the Session Management spec (which should define PAPE
binding for re-auth).

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



-- 
--Breno


More information about the Openid-specs-ab mailing list