Question. In the proposal, how does google know that the request is
being presented by "acct:dbou...@cliqset.com"? Is the secret used for
the magic signature in the first request, the user's private key? So in
this case cliqset.com would have dbounds' private key in order to
generate the signature? (This seems to be implied from the oauth-push
doc; at least from my reading).
I love the idea of allowing access to protected resources by individuals
that do not have an "account" at the provider. This is a critical next
step in the set of capabilities supported by OAuth and other
technologies. However, I'm not quite show how the provider verifies the
presented user identifier. Meaning, how does the provider protect
against me specifying someone else's identifier and getting access to
the protected resource.
Thanks,
George
On 7/29/10 12:43 PM, Darren Bounds wrote:
Thanks James. Comments are inline.
It sounds like you want to use OAuth2 to insert an human/HTML interaction into
a app/Atom exchange.
The proposal was designed to provide a single flow that would
accommodate 0 or more human interaction requirements. Additionally,
the scope should not limited to access protected feed but rather any
protected resource.
While the example usecase illustrated access to a protected feed, you
can imagine this being used in more traditional flow scenarios, such
as that of the Web Server client profile.
For example, if a user has already negotiated an access token in the
proposed manner, additional access tokens *could* be granted on the
user's behalf without the requirement of a redirect.
OAuth2 can do that.
You also want to use a direct OAuth2 flow for access control to the feed.
Your "precondition_uri" addition to the token response is an attempt to combine
the 2 OAuth2 flows.
I'd say it's an attempt to create a new flow that's more flexible and
suitable for the type of interactions DiSo requires.
An alternative would be to run the 2 OAuth2 flows sequentially.
1. app use a direct OAuth2 flow (eg the assertion flow) to get a token;
2. app tries to get feed with token, but server demands a user-delegation
OAuth2 flow;
3. app redirects user to service; Terms of Service are shown; user redirected
back;
4. app tries to get feed again, which succeeds this time.
This example illustrates that OAuth2 discovery needs to let a service
explicitly indicate whether a direct and/or user-delegation flow is required.
For instance, a "WWW-Authenticate: OAuth2" response could define 2 parameters:
'user-uri' and 'token-uri'. If only one is present, only the corresponding mode
is useful in this interaction.
Interesting.
Another interesting facet of this example is what token the app uses
at step 4. Is it the token the app got in the first OAuth2 flow (step 1),
or the token from the second OAuth2 flow (step 3)?
Presumably the second token overrides the first.
In this example, however, it may be sufficient to keep using the first token.
OAuth2 doesn’t need to make returning a token mandatory -- it is not
always required in a user-delegation flow.
Also, when the user delegation flow is executed (step 3), how does the
provider associate acknowledgement of the ToS with the assertion grant
(step 1)?
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
