> 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
<https://authorization-server.com/user/5035678642>",
"userinfo_at": "b0Dl3KsXXOGc7tWfFLZYv7G5bXk"
}
}
>
>
>
> On Fri, Jul 19, 2019 at 11:42 PM Neil Madden <neil.mad...@forgerock.com
> <mailto: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
> <mailto: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
>> <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
>> <https://aaronparecki.com/2019/07/18/17/adding-identity-to-xyz>
>>
>> Thanks!
>>
>> ----
>> Aaron Parecki
>> aaronparecki.com <http://aaronparecki.com/>
>> @aaronpk <http://twitter.com/aaronpk>
>>
>>
>>
>> On Tue, Jul 9, 2019 at 2:48 PM Justin Richer <jric...@mit.edu
>> <mailto: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
>> <https://tools.ietf.org/html/draft-richer-transactional-authz-02>
>>
>> Additionally, I’ve updated the writeup and examples on https://oauth.xyz/
>> <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 <mailto:OAuth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth
>> <https://www.ietf.org/mailman/listinfo/oauth>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth
>> <https://www.ietf.org/mailman/listinfo/oauth>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth
> <https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
