Absolutely, however, I believe the atomic units that make up the OAuth
profile spectrum have not properly taken into account the tidal wave
of DiSo interactions that are forth coming. Subsequently you can force
them into place and say "they work" but IMO will have a hard time
achieving adoption du
ts allows a simple way to
> minimize on one path.
>
>> -Original Message-
>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org]
>> On Behalf Of Manger, James H
>> Sent: Tuesday, August 03, 2010 8:01 PM
>> To: Torsten Lodderstedt
>> Cc: oauth@
>
>> In my opinion, this decision is up to the authorization server and not
>> the resource server. Or should both be possible? What do you think?
>
> Theoretically, the decision should probably be up to the authorization server.
> In practise, however, the decision should be *delivered* from t
, James H
> Sent: Tuesday, August 03, 2010 8:01 PM
> To: Torsten Lodderstedt
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] OAuth & Protected feeds
>
> Torsten,
>
> >> This example illustrates that OAuth2 discovery needs to
> let a service
> >> explici
Torsten,
>> 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 pre
egroups.com;
federated-social-...@googlegroups.com
Subject: [OAUTH-WG] OAuth& Protected feeds
Please excuse the cross posting.
Following the Federated Social Web Summit in Portland a couple weeks
ago, there has been a lot of chatter around protected feeds and how
they'll function to achieve SW
required in a user-delegation flow.
--
James Manger
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Darren Bounds
Sent: Thursday, 29 July 2010 6:29 AM
To: oauth@ietf.org; pubsubhub...@googlegroups.com;
federated-social-...@googlegroups
Darren,
As an OAuth 2 provider and consumer as well as someone who's preparing
to build the DiSo interactions my proposal was based on, I would
prefer a single flow that addresses what I feel will be a increasingly
common set of requirements rather than combining two flows designed
for two distin
James,
> precondition_uri seems to address a requirement for optional human interaction
> when an app starts accessing a protected resource.
> A solution that changes the token response can only add the human interaction:
> a) if OAuth is used for direct authentication/authorization of the app; an
Darren,
>> 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.
precondition_uri seems to address a requirement for opt
Torsten,
Yes. Federation is the basis for proposal. Federated social interactions.
The value is that the provider is able to verify the assertion that
user dbounds on host cliqset.com has requested access token which it
will use to access and/or request access to protected resources within
the go
So what the value of that assertion? The authz server cannot
authenticate the user (probably not even identify). Or do you assume
some kind of federation between the two domains?
Am 29.07.2010 20:36, schrieb Darren Bounds:
Yes, but with no requirement that the user have an account on the
provi
Thanks George. My response is inline.
On Thu, Jul 29, 2010 at 2:51 PM, George Fletcher wrote:
> 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 priva
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 signa
Yes, but with no requirement that the user have an account on the
provider. It is merely an assertion the UserA on HostX made the
request.
On Thu, Jul 29, 2010 at 1:05 PM, Torsten Lodderstedt
wrote:
> So this assertion is conceptually equivalent to a case where the client
> would have sent userna
So this assertion is conceptually equivalent to a case where the client
would have sent username and password of dbounds at the authz server. Is
this correct?
Am 29.07.2010 17:32, schrieb Darren Bounds:
Torsten,
The URI represents an end-user at a domain. Through this assertion the
provider i
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 limite
Torsten,
The URI represents an end-user at a domain. Through this assertion the
provider is able to verify the magic signature and thus confirm user
dbounds at host cliqset.com has requested an access token.
References:
http://code.google.com/p/webfinger/wiki/WebFingerProtocol
http://salmon-proto
--
James Manger
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Darren Bounds
Sent: Thursday, 29 July 2010 6:29 AM
To: oauth@ietf.org; pubsubhub...@googlegroups.com;
federated-social-...@googlegroups.com
Subject: [OAUTH-WG] OAuth & Prot
Darren,
I have got some questions regarding your posting, esp. the assertion.
1) cliqset.com would like to request an access token from google.com.
Sends a request with grant_type=assertion.
Request:
POST /token HTTP/1.1
Host: google.com
Content-Type: application/x-www-form-urlencoded
grant_ty
Folks interested in protected feeds may be interested in UMA's solution, which
proposes mechanisms to demand "claims" from the requesting side based on
user-specified policyon the authorizing server side. An example of
UMA-protected resources that require agreement to terms can be seen in the
Please excuse the cross posting.
Following the Federated Social Web Summit in Portland a couple weeks
ago, there has been a lot of chatter around protected feeds and how
they'll function to achieve SWAT0
(http://federatedsocialweb.net/wiki/SWAT0). Protected feed
subscriptions are clearly an impor
22 matches
Mail list logo
