Here is where I see the differences...
#2 forces "person B" to go through an authentication event at
photos.example.com
while #3 allows the client "person B" is using to get the access token
at time of authentication to the client.
So, for #2 "person B" will likely have to do 2 authenticati
On Sun, Jun 6, 2010 at 8:14 PM, Manger, James H > Defining an optional
prefix for access_token values to indicate the format would work well.
> I suggest a plain text label separated by, say, a "." from the rest of the
> value. For example:
> access_token=saml.fhHFhgf6575fhgFGrytr
> There can be
On Tue, Jun 8, 2010 at 7:17 AM, George Fletcher >
2. Use OpenID and force Person B to "sign in" to photos.example.com
> (effectively establishing a relationship with photos.example.com that they
> might not want)
>
> 3. Have photos.example.com be able to accept a token from person B's
> authorizat
On 6/8/10 9:58 AM, Luke Shepard wrote:
Again: can you provide a specific, real-world example where this is
necessary? I'd rather not deal in hypotheticals. I've already answered
the case of a hypothetical endpoint that accepts both SAML and
JSON-encoded tokens.
I believe one such case is person
>> Client simplicity (code and mental model).
>
> I think the difference in simplicity between one parameter and two is not
> such that it requires munging the two together.
>
> The token_string and the token_format are two different parts of the token.
If you look through my emails, I provide
On Jun 7, 2010, at 8:25 PM, Manger, James H wrote:
> John,
>
>>> access_token=saml.fhHFhgf6575fhgFGrytr
>
>> What is the advantage of doing it this way over having a separate field?
>
> Client simplicity (code and mental model).
I think the difference in simplicity between one parameter and t
John,
>> access_token=saml.fhHFhgf6575fhgFGrytr
> What is the advantage of doing it this way over having a separate field?
Client simplicity (code and mental model).
> What if the format is a URI?
That is a choice between the AS and PR that is irrelevant to the client app --
so why should th
On Jun 6, 2010, at 11:14 PM, Manger, James H wrote:
> OAuth2 has a field for AS-to-PR communications via (but opaque to) the
> client: access_token. Any format indication (like a variety of other details)
> that an AS wants to convey to the PR via the client app should be *inside*
> this existi
(resending to DL due to apparent DL failure over the weekend... I know Dick
and Luke already received my email because they were individual recipients
as well... I don't know if the DL received their replies or not)...
Great discussion, all. I am also for an optional parameter that's part of
the
OAuth2 has a field for AS-to-PR communications via (but opaque to) the client:
access_token. Any format indication (like a variety of other details) that an
AS wants to convey to the PR via the client app should be *inside* this
existing field.
Defining an optional prefix for access_token value
On 2010-06-04, at 6:39 PM, Luke Shepard wrote:
> I don't see how the extra parameter is required to support multiple auth
> servers for a resource.
it is needed if there are multiple token types
>
> Responses to Dick and Torsten:
>
> On Jun 4, 2010, at 11:33 AM, Dick Hardt wrote:
>> if we ha
I don't see how the extra parameter is required to support multiple auth
servers for a resource.
Responses to Dick and Torsten:
On Jun 4, 2010, at 11:33 AM, Dick Hardt wrote:
> if we have the parameter in the spec, then clients know to pass it along if
> they see it.
My main objection here i
Torsten,
On Jun 4, 2010, at 2:31 PM, Torsten Lodderstedt wrote:
>
> Am 04.06.2010 19:45, schrieb John Kemp:
>> On Jun 4, 2010, at 1:35 PM, David Recordon wrote:
>>
>>
>>> #4 should happen as part of #3.
>>>
>> How would ALL OAuth 2.0+ clients know to pass along the format if it is
>> t
1. ++
2. ++
3. ++
4. ++ as a part of 3., otherwise --
-- justin
On Fri, 2010-06-04 at 12:58 -0400, George Fletcher wrote:
> Could I conclude then that "we" are all in "agreement"? :)
>
> 1. OAuth 2.0 should not require a structured token (i.e. don't break
> existing use cases)
> 2. OAuth 2.0 s
You earlier stated that multiple AS was out of scope. I am aligned that
using OAuth 2.0 needs to support the widely deployed social web use cases --
if you recall, I drove getting rid of the signature requirement! :)
On Fri, Jun 4, 2010 at 9:45 AM, Luke Shepard wrote:
>
> On Jun 4, 2010, at 8:41
David, are you saying the optional parameter should be a separate spec, or
that #3 and #4 are the same thing? (I disagree with both L)
I see a new, standard token and specifying the token format are orthogonal.
The PR may accept multiple proprietary token types.
if we have the parameter in the sp
Am 04.06.2010 19:45, schrieb John Kemp:
On Jun 4, 2010, at 1:35 PM, David Recordon wrote:
#4 should happen as part of #3.
How would ALL OAuth 2.0+ clients know to pass along the format if it is there?
I fail to see the problem with specifying an optional token format parameter in t
On Jun 4, 2010, at 1:35 PM, David Recordon wrote:
> #4 should happen as part of #3.
How would ALL OAuth 2.0+ clients know to pass along the format if it is there?
I fail to see the problem with specifying an optional token format parameter in
the main spec. and giving it a default value, and se
#4 should happen as part of #3.
On Fri, Jun 4, 2010 at 9:58 AM, George Fletcher wrote:
> Could I conclude then that "we" are all in "agreement"? :)
>
> 1. OAuth 2.0 should not require a structured token (i.e. don't break
> existing use cases)
> 2. OAuth 2.0 should not prohibit resource owners s
Could I conclude then that "we" are all in "agreement"? :)
1. OAuth 2.0 should not require a structured token (i.e. don't break
existing use cases)
2. OAuth 2.0 should not prohibit resource owners supporting multiple
Authentication Servers
3. OAuth 2.0 should allow for structured tokens via a
On Jun 4, 2010, at 8:41 AM, Dick Hardt wrote:
> There is more to the web than the social web Luke, and supporting multiple AS
> has been a design goal of WRAP and OAuth 2.0 and is being implemented.
Whoa, I didn't say there wasn't. I agree that supporting multiple authorization
servers is a re
+1 (just in case that was not clear from my other emails :)
On 2010-06-04, at 8:57 AM, Torsten Lodderstedt wrote:
> +1 for an optional "token_format" attribute/parameter
>
> Am 04.06.2010 17:21, schrieb John Kemp:
>> Hi Luke,
>>
>> On Jun 4, 2010, at 11:00 AM, Luke Shepard wrote:
>>
>>
>>>
+1 for an optional "token_format" attribute/parameter
Am 04.06.2010 17:21, schrieb John Kemp:
Hi Luke,
On Jun 4, 2010, at 11:00 AM, Luke Shepard wrote:
On Jun 4, 2010, at 7:19 AM, George Fletcher wrote:
On 6/4/10 9:53 AM, Luke Shepard wrote:
Having a single resource serve
On 6/4/10 9:23 AM, Justin Richer wrote:
>> We should solve one problem at a time. It's easy to layer structure
>> on top of an opaque blob in a separate spec.
>
> +1 to this. Token structure seems like a nice idea, but it's outside
> what should be dictated by the OAuth spec. We want people to b
On Fri, Jun 4, 2010 at 8:00 AM, Luke Shepard wrote:
>
> On Jun 4, 2010, at 7:19 AM, George Fletcher wrote:
>
> > On 6/4/10 9:53 AM, Luke Shepard wrote:
> >>
> >> Having a single resource server that works with multiple independent
> auth servers is not in scope for OAuth. That said, there's nothi
On Fri, Jun 4, 2010 at 8:23 AM, Justin Richer wrote:
> > We should solve one problem at a time. It's easy to layer structure
> > on top of an opaque blob in a separate spec.
>
> +1 to this. Token structure seems like a nice idea, but it's outside
> what should be dictated by the OAuth spec. We wa
> We should solve one problem at a time. It's easy to layer structure
> on top of an opaque blob in a separate spec.
+1 to this. Token structure seems like a nice idea, but it's outside
what should be dictated by the OAuth spec. We want people to be able to
use OAuth to shuttle their existing to
Hi Luke,
On Jun 4, 2010, at 11:00 AM, Luke Shepard wrote:
>
> On Jun 4, 2010, at 7:19 AM, George Fletcher wrote:
>
>> On 6/4/10 9:53 AM, Luke Shepard wrote:
>>>
>>> Having a single resource server that works with multiple independent auth
>>> servers is not in scope for OAuth. That said, ther
On Jun 4, 2010, at 7:19 AM, George Fletcher wrote:
> On 6/4/10 9:53 AM, Luke Shepard wrote:
>>
>> Having a single resource server that works with multiple independent auth
>> servers is not in scope for OAuth. That said, there's nothing to stop
>> multiple servers to agree amongst themselves t
This is exactly the direction UMA is headed (as George knows :-), since we
*are* trying to solve for "unmooring" authorization servers and resource
servers -- which we call authorization managers and hosts.
The absolute simplest thing to do is hand out tokens that are essentially
artifacts that
On 6/4/10 9:53 AM, Luke Shepard wrote:
Having a single resource server that works with multiple independent
auth servers is not in scope for OAuth. That said, there's nothing to
stop multiple servers to agree amongst themselves to have a
standardized format for access token- and if necessary, t
+1 to some standardization to the token
The URI would also allow for discovery and the ability for the provider
to define an endpoint in the XRD for the URI that allows "dumb mode"
token validation. This way, even if the resource owner doesn't know how
to "crack" the token locally, they could
+1, but why only partially?
I would like to add another use case for a standardized token format.
Suppose a software vendor wants to built and sell a standard software
component (service), e.g. an address book service, which is secured
using OAuth2. Having a standardized token format would ma
Having a single resource server that works with multiple independent auth
servers is not in scope for OAuth. That said, there's nothing to stop multiple
servers to agree amongst themselves to have a standardized format for access
token- and if necessary, to write that agreement as a separate spe
Having just implemented OAuth 2.0 web server flow, it was great to be able
to issue an "opaque" access token to the client. This access token is in an
encrypted format that only the resource server understands. I feel pretty
good about this approach as it lends to high security and tokens that on
35 matches
Mail list logo
