Hans,
Agreed. There is an elegance to it, kind of the micro format way
(if one squints ;o)).
And I am absolutely fine with arbitrary domain-specific
formats. But still there are certain assumptions latent in the spec
which sometimes might not be apparent.
You are right, the token format is undefined, which means most
probably we cannot assume it will be the same on it's way back in step
#d in the flow diagram (of course, if included, as the token is
optional).
Anyway, good point and thanks. And I am fine both ways i.e.
either assume the requestToken never changes or that it could change on
it's way back from user authZ.
Cheers
<k/>
|-----Original Message-----
|From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf
|Of Hans Granqvist
|Sent: Sunday, February 01, 2009 12:57 PM
|To: oauth@googlegroups.com
|Subject: [oauth] Re: Problem accessing OAuthAccessToken
|
|
|Krishna, whereas SAML defines the token format, OAuth doesn't, so this
|is an intended
|side-effect: the possible perfect forward security of tokens, if the
|issuer so desires. It is
|kinda sorta elegant, but it adds some complexity.
|
|
|On Sun, Feb 1, 2009 at 10:39 AM, Krishna Sankar (ksankar)
|<ksan...@cisco.com> wrote:
|>
|> John,
|> Good point and thanks for the details. I think we are talking
|about the same thing, but possibly in a slightly different context. Let
|me elaborate my understanding.
|>
|> a) In steps #c and #d of the flow diagram, the
oauth_token
|is optional. So, in cases, where it is not used, the unauthorized &
|authorized requestTokens would be the same
|>
|> b) Yep, the act of Step 2, will change the state of the
|SP. But that does not necessarily mean that the state would be
persisted
|at the SP side.
|>
|> c) In 6.2.1, the SP can require the oauth_token (the
|unauthorized requestToken, in this case) be present for step #c. And it
|can require a callback URL be present.
|>
|> d) In which case, in step #d an oauth_token (the
|authorized requestToken, in this case) would be sent back - section
|6.2.3
|>
|> e) The spec does not say clearly if the token sent back
in
|6.2.3 is the same as the one in 6.2.1
|>
|> f) Couple of scenarios I was looking at have the
|(possibility of the) OAuth engine separate and loosely coupled with the
|services. For example OAuth engine in a firewall or a separate OAuth
|service for a collection of UC services. In all these cases, embedding
|the state in the token is attractive. Having said that, thanks for this
|discussion, I doubt now, if one can really afford not to go back to the
|OAuth engine to check the state. While it might be choreographically
|possible, it might not be wise from a security perspective.
|>
|> g) In any case, I would like to get the insight on the
|inclusion of the tokens in 6.2.1 and 6.2.3. If they are the same, why
|exchange them ? Is it for the optimization at the consumer side ? Were
|there any other scenarios ? And why call them by two names - authorized
|and unauthorized tokens - if they are the same ? Thoughts ?
|>
|> Cheers
|> <k/>
|>
|> |-----Original Message-----
|> |From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On
|Behalf
|> |Of John Kristian
|> |Sent: Saturday, January 31, 2009 6:56 PM
|> |To: OAuth
|> |Subject: [oauth] Re: Problem accessing OAuthAccessToken
|> |
|> |
|> |We're not communicating clearly, I fear. Let's use the terms from
|the
|> |OAuth Core 1.0 specification section 6
|> |http://oauth.net/core/1.0/#anchor9
|> |
|> |There are two tokens: a request token and an access token. The
|> |service provider chooses the tokens. They may be different. The
|> |service provider may pack data into the tokens, but this isn't
|> |specified by OAuth.
|> |
|> |There are three steps:
|> |
|> |1. The Consumer obtains an unauthorized Request Token.
|> |2. The User authorizes the Request Token.
|> |3. The Consumer exchanges the Request Token for an Access Token.
|> |
|> |Step 2 doesn't produce a new token. It changes state in the service
|> |provider, so the service provider associates authority (permission)
|> |with the request token.
|> |
|> |On Jan 31, 3:07 pm, "Krishna Sankar (ksankar)" <ksan...@cisco.com>
|> |wrote:
|> |> I thought they *need not* be the same - because a service
|> |> provider could conceivably encode some opaque values in the
|> |> tokens and those might be different in the unauthorized &
|> |> authorized requestTokens. I am actually planning on these
|> |> two being different. Does the spec specify that these two
|> |> tokens should be the same ?
|> |
|> |
|>
|> >
|>
|
|
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~----------~----~----~----~------~----~------~--~---
