In my view, the RPT has *always* been an access token, so I don’t agree with Eve’s stance below. The UMA2 work is aligning more explicitly with how I’d personally always looked at it.That said, I’ve also never been a fan of the token profiles and other extension-from-zero-examples aspects of UMA. It’s my personal preference to get rid of them until such time as they’re needed and there’s a demonstrable thing to extend it with in a meaningful way. The problem with having an extension point and only one thing defined in it is that it invites implementors to get lazy and assume that things will always be this way. I think we’ve already seen this with most OAuth clients and the “token_type” parameter for bearer tokens. Since bearer tokens are the only tokens that shipped in 2012 (the MAC token spec got dropped by the group at the time), most OAuth clients don’t even check the field when parsing the token response. I wouldn’t be surprised if the same kind of assumptions were true of UMA1 implementations (I’m pretty sure it’s true of ours, at least).So with that in mind, I don’t really think that we need the profile/extension points (and associated MTI) as they are written in to UMA1.— JustinOn Oct 20, 2016, at 3:56 AM, Eve Maler <eve@xmlgrrl.com> wrote:The RPT hasn't been entirely a "plain" OAuth access token in UMA1, which is why I raised all the questions I did regarding UMA2. At least, I think that's true, to the extent that introspecting it would give a very customized answer.Would you agree that's true? My questions in this thread were based on trying to figure out what in our spec should/must/shouldn't change, based on aligning more closely with OAuth current practice, and guessing that whole bunches of stuff could be taken out.Basically, in the case of bearer tokens, could we get rid of the whole notion of an MTI UMA Bearer token profile, and possibly reference 6750, but would we still have to say something about the format of an introspected object (or locally validated token format) that contains explicit resource sets with scopes, vs. just scope strings? And to Cigdem's point, is it worth mentioning PoP tokens and therefore "porting" all of this to a PoP world?______________________________On Tue, Oct 18, 2016 at 2:01 PM, Cigdem Sengul <Cigdem.Sengul@nominet.uk> wrote:Hello James,
I did only consider tokens indeed, instead of permission tickets. I am also not sure how that would work with the permission ticket.
For RPT and PAT OAuth2 tokens: I think bringing the option up may be useful. It is not a MUST of course.
I understand that the choice is left to the implementation which type of tokens to use etc.
--Cigdem
From: James Phillpotts <james.phillpotts@forgerock.co
m >
Date: Tuesday, 18 October 2016 at 13:32
To: Cigdem Sengul <Cigdem.Sengul@nominet.uk>
Cc: "wg-uma@kantarainitiative.org WG" <wg-uma@kantarainitiative.org>
Subject: Re: [WG-UMA] Section 7 - Security considerations - bearer tokens
Hi Cigdem,
Is that for the PCT? The RPT and PAT are OAuth 2 tokens, so would be separately covered by the specs for OAuth 2 PoP, so I wouldn't have thought we need to say much about that. Not sure how PoP would work with the permission ticket.
Cheers,
James
On 18 October 2016 at 09:20, Cigdem Sengul <Cigdem.Sengul@nominet.uk> wrote:
Hello,
Eve suggested that I start the discussion about this in the list.
Regarding the security concerns about the bearer tokens in the draft, I was curious whether it is worth mentioning Proof-of-Possession (PoP) tokens.
In addition, RFC 6750 recommendations may also be referred to in the draft.
Thanks,
--Cigdem
_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma
_______________________________________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma
_________________
WG-UMA mailing list
WG-UMA@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-uma