As written in the I-D, the use case does call for person-to-person sharing,
which OAuth in its current state doesn't really cover. If you do want to
achieve that outcome, User-Managed Access, built on top of OAuth, specializes
in it. You can find out more at
http://kantarainitiative.org/conflue
More like, Bill (client/resource owner) wants to authorize and generate
a token for App-B.
On 3/12/2012 00:10, William Mills wrote:
So Bob has already issued credentials to App-A and now needs to
authorize App-B?
So Bob has already issued credentials to App-A and now needs to authorize App-B?
>
> From: David Fox
>To: William Mills
>Cc: 'OAuth WG' ; swee...@au1.ibm.com
>Sent: Sunday, March 11, 2012 9:47 PM
>Subject: Re: [OAUTH-WG] Issue token for another user
>
>
>@S
@Shane: Good point, and in my application the user/client would be
authorizing another registered program. Was just using Bob to keep with
the example.
@William:
1. I'm just building the API now so anything is possible, but could you
give me an example of what you mean?
2. Sure will do, though
Can you specify the user being accesses as the resource in the URL?
P.S. Please start using the
http://twiki.corp.yahoo.com/view/Paranoidyahoos/SecurityRequest for new
requests like product and feature reviews.
>
> From: David Fox
>To: 'OAuth WG'
>Sent
IMO the scenario as documented doesn't make complete sense in the context
of OAuth 2.0 as it says that Bob uses the access token to access Alice's
photos. Clients in OAuth 2.0 are not people, they are programs.
From: David Fox
To: "'OAuth WG'"
Date: 12/03/2012 12:15 PM
Subject:
http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases-02#section-3.8
In order to achieve the use case above, how would the client (a.k.a the
resource owner in this case) specify which user to authorize?
Would the correct approach be to make a request to the Authorization
Server with the gr
I understood.
Thanks.
--
nov
On Mar 12, 2012, at 2:30 AM, Eran Hammer wrote:
> That use case was removed from the specification. Either way, it is up to the
> authorization server to decide which registration options to offer the client
> if they make such a grant type available in the future
That use case was removed from the specification. Either way, it is up to the
authorization server to decide which registration options to offer the client
if they make such a grant type available in the future, and how it will apply
the security policies. IOW, those proposing such an extension
So what is the usecase of response_type=token%20code ?
I thought, in that usecase, token was for the client's client-side component,
code was for the client's server-side component, and both of them have the same
client_id.
--
nov
On Mar 12, 2012, at 12:57 AM, Eran Hammer wrote:
> If you have
+1
From: oauth-boun...@ietf.org [oauth-boun...@ietf.org] on behalf of Brian
Campbell [bcampb...@pingidentity.com]
Sent: Sunday, March 11, 2012 9:50 AM
To: John Bradley
Cc: oauth
Subject: Re: [OAUTH-WG] question about the b64token syntax in
draft-ietf-oauth-v2-bear
If you have two components each with different security profile, you must
assign each a different client_id. Otherwise, there is no way to enforce the
rest of the spec's security requirements.
EH
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Beha
Hi,
I just found this sentence in the latest draft.
Does it mean "an application consisting of server-side and client-side
component (eg. foursquare iPhone app) MUST have separate client_id for each
component" ?
Or can I image something like Facebook is doing right now? (register each
componen
+1
On Mar 11, 2012 7:08 AM, "John Bradley" wrote:
> +1
>
> Sent from my iPhone
>
> On 2012-03-10, at 12:49 PM, Mike Jones
> wrote:
>
> I plan to make the change to the example access token value to
> mF_9.B5f-4.1JqM before Monday’s submission deadline, per the requests for
> b64token syntax cla
+1
Sent from my iPhone
On 2012-03-10, at 12:49 PM, Mike Jones wrote:
> I plan to make the change to the example access token value to
> mF_9.B5f-4.1JqM before Monday’s submission deadline, per the requests for
> b64token syntax clarification. I’m also considering adding an access token
> re
+1
On 3/11/12 6:05 AM, Manger, James H wrote:
+1
--
James Manger
- Reply message -From: "Mike Jones" Date: Sun, Mar 11, 2012 4:50 am Subject: [OAUTH-WG]
question about the b64token syntax in draft-ietf-oauth-v2-bearer To: "Paul Madsen", "Brian
Campbell" Cc: "oauth"
I plan to make
+1
--
James Manger
- Reply message -From: "Mike Jones" Date:
Sun, Mar 11, 2012 4:50 am Subject: [OAUTH-WG] question about the b64token
syntax in draft-ietf-oauth-v2-bearer To: "Paul Madsen" ,
"Brian Campbell" Cc: "oauth"
I plan to make the change to the example access token value t
17 matches
Mail list logo
