Hi Neil
I see that you are looking at how to modify Justin's proposal, and I'm
looking at what are the requirements.
Ignoring the specifics, is there a reason why multiple tokens need to be
returned in the same request?
On Mon, Jul 22, 2019 at 9:41 AM Neil Madden <neil.mad...@forgerock.com>
wrote:
>
> On 21 Jul 2019, at 22:22, Dick Hardt <dick.ha...@gmail.com> wrote:
>
> Hi Neil, I agree that an access token that is usable across resources is
> problematic.
>
> How are you thinking multiple access tokens would be returned?
>
>
> Well there are lots of possible ways, e.g.:
>
> {
> "tokens": [
> { "resource": "https://res1";, "access_token": "..." },
> { "resource": "res2", ...}, ...
> ]
> }
>
> I'm not particularly wedded to any format.
>
> Why do you think the request needs to return multiple tokens rather than
> making a separate request for each token? That would seem to simplify the
> request and response as context would only need to provided for the one
> access token.
>
>
> Note that in Aaron's proposal we have a "user" section on (presumably)
> every access token response, which indicates a userinfo endpoint that
> itself needs an access token. So either the same access token is used to
> access that userinfo endpoint (which means that the RS can also access the
> userinfo endpoint), or else we already need to return a second access token
> in the same request, e.g.:
>
> {
> "access_token": {
> "value": "UM1P9PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",
> "type": "bearer"
> },
> "user": {
> "id": "5035678642",
> "userinfo": "https://authorization-server.com/user/5035678642";,
> "userinfo_at": "b0Dl3KsXXOGc7tWfFLZYv7G5bXk"
> }
> }
>
>
>
>
> On Fri, Jul 19, 2019 at 11:42 PM Neil Madden <neil.mad...@forgerock.com>
> wrote:
>
>> If we’re going to redesign OAuth, one improvement would be to allow a
>> client to request different access tokens for different resource servers in
>> a single request. That should include issuing a different access token for
>> the userinfo endpoint vs other RSes.
>>
>> One of the weaknesses of combined OAuth + OIDC use now is that if you
>> request OIDC scopes and scopes for another resource in the same request
>> then you inadvertently give those other RSes access to the user’s profile.
>>
>> — Neil
>>
>> On 20 Jul 2019, at 01:02, Aaron Parecki <aa...@parecki.com> wrote:
>>
>> Hi all, I'm looking forward to the discussion on this on Tuesday!
>>
>> I wanted to add my thoughts on a potential addition to this draft,
>> specifically around returning some minimal user information in the
>> transaction response.
>>
>> The summary of the suggestion is to return a new "user" key along with
>> the access token that contains the user ID and userinfo endpoint, such as:
>>
>> {
>> "access_token": {
>> "value": "UM1P9PMHKUR64TB8N6BW7OZB8CDFONP219RP1LT0",
>> "type": "bearer"
>> },
>> "user": {
>> "id": "5035678642",
>> "userinfo": "https://authorization-server.com/user/5035678642";
>> }
>> }
>>
>> A more detailed analysis of the specific proposal and motivation behind
>> this is available on my blog:
>>
>> https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz
>>
>> Thanks!
>>
>> ----
>> Aaron Parecki
>> aaronparecki.com
>> @aaronpk <http://twitter.com/aaronpk>
>>
>>
>>
>> On Tue, Jul 9, 2019 at 2:48 PM Justin Richer <jric...@mit.edu> wrote:
>>
>>> I have requested time to present Transactional Authorization (the XYZ
>>> project) at the Montreal meeting in a couple weeks. Ahead of that, I’ve
>>> uploaded a new version of the spec:
>>>
>>> https://tools.ietf.org/html/draft-richer-transactional-authz-02
>>>
>>> Additionally, I’ve updated the writeup and examples on
>>> https://oauth.xyz/
>>>
>>> I plan to be in Montreal for the whole week, and I’ve requested from the
>>> chairs that I present during the Tuesday session due to limited
>>> availability of some key WG members on Friday.
>>>
>>> — Justin
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
