[Openid-specs-ab] Redirect URL or URI?

[Breno de Medeiros]

On Thu, Jul 28, 2011 at 20:17, Mike Jones <Michael.Jones at microsoft.com> wrote:
> What about the js_origin_url?  Can these actually be URNs and not URLs as well?

I am not so sure. They certainly don't need to be HTTP URLs. E.g.:
chrome-extension://qpowieruqwpoeiru could be used to send a
postmessage response to a chrome extension client. One can imagine
custom URL schemes to activate an iOS application (or any other OS
that allows 'app dispatch by URL').


>
>                                -- Mike
>
> -----Original Message-----
> From: Breno de Medeiros [mailto:breno at google.com]
> Sent: Thursday, July 28, 2011 4:49 PM
> To: Mike Jones
> Cc: Casper Biering; openid-specs-ab at lists.openid.net
> Subject: Re: Redirect URL or URI?
>
> On Thu, Jul 28, 2011 at 16:39, Mike Jones <Michael.Jones at microsoft.com> wrote:
>> Another question from the call:  Is there some circumstance in which
>> the redirect URL can actually be an URN, rather than a URL?  In that
>> case, Casper's proposed change of redirect_url to redirect_uri would make sense.
>> But if it can only be a URL, it doesn't.  (Yes, OAuth called it a URI,
>> but in the OpenID specs, we've tried to be consistent in naming things
>> that can only be URLs URL, versus things that can be URNs URIs.)
>
> 1. Please don't change conventions vs. OAuth2. We already have made some harmful choices in this regard.
>
> 2. Redirect URLs can be URNs. Examples are native apps and postmessage flows.
>
>>
>>
>>
>>                                                             Thanks
>> again,
>>
>>                                                             -- 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
>



-- 
--Breno