Section 7 - Security considerations - bearer tokens
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
Thank you, Cigdem! This ties into additional topics in the main body of the spec as well, since we're now up to the point of figuring out things like: - Can we now remove the MTI (mandatory-to-implement) requirement to introspect tokens, and just let RPTs be whatever kind of OAuth access tokens? -If so, if introspected, does the result still have to be profiled due to the resource set superstructure vs just scopes? - What does this mean for the UMA Bearer token profile? Should it go away, morph, stay the same? - What to say explicitly about refresh tokens, if anything? - What to say explicitly about PoP tokens, if anything? Note that we had discussed some of these potential "added options" under the #IoT roadmap item, e.g., being able to do local token validation at the RS instead of introspection at the AS. Oh, and we do have a tiny oblique mention of PoP in the following section ("holder-of-key-type approach")... We might want to update this now that time has marched on, especially once we've figured out our main-spec approach. https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-05.html#redirect-thre... Eve Maler (sent from my iPad) | cell +1 425 345 6756
On Oct 18, 2016, at 9:20 AM, 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
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
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.com> 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<mailto: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<mailto:WG-UMA@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/wg-uma
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? *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl 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.com> *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
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. — Justin
On 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?
Eve Maler Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
On Tue, Oct 18, 2016 at 2:01 PM, Cigdem Sengul <Cigdem.Sengul@nominet.uk <mailto: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.com <mailto:james.phillpotts@forgerock.com>> Date: Tuesday, 18 October 2016 at 13:32 To: Cigdem Sengul <Cigdem.Sengul@nominet.uk <mailto:Cigdem.Sengul@nominet.uk>> Cc: "wg-uma@kantarainitiative.org <mailto:wg-uma@kantarainitiative.org> WG" <wg-uma@kantarainitiative.org <mailto: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 <mailto: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 <mailto:WG-UMA@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/wg-uma <http://kantarainitiative.org/mailman/listinfo/wg-uma>
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org <mailto:WG-UMA@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/wg-uma <http://kantarainitiative.org/mailman/listinfo/wg-uma>
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
Okay. I certainly understand the direction and the desire. That said, in UMA1, how do you deal with the MTI token profile, if at all? Did you implement it but not use it with any clients? When it comes to the resource set ID layer of permissions, do you just hand over a pile of scopes to the RS that happen to be named in such a way that they don't overlap per resource set ID? *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Fri, Oct 21, 2016 at 12:31 PM, Justin Richer <jricher@mit.edu> wrote:
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.
— Justin
On 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?
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
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.com> *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
We just implement the only option (which is MTI) and don’t check any of the “here’s what’s implemented” fields. This is what I mean by a lazy implementation of a single option in an extension point. There’s not really anything profiled here other than the introspection response. The RS’s use that to determine whether the call being made applies to them. There’s no real worry or danger of scope overlap with the way the data structures are set up: scopes are subservient to resource set identifiers. Since the resource set gets to define the scope (and really, its’ the API the resource set is providing that defines the scope), then there’s no chance of overlap because it’s all internal to the resource set. There is zero need for profiling to make that work. — Justin
On Oct 21, 2016, at 2:37 PM, Eve Maler <eve@xmlgrrl.com> wrote:
Okay. I certainly understand the direction and the desire. That said, in UMA1, how do you deal with the MTI token profile, if at all? Did you implement it but not use it with any clients? When it comes to the resource set ID layer of permissions, do you just hand over a pile of scopes to the RS that happen to be named in such a way that they don't overlap per resource set ID?
Eve Maler Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
On Fri, Oct 21, 2016 at 12:31 PM, Justin Richer <jricher@mit.edu <mailto:jricher@mit.edu>> wrote: 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.
— Justin
On Oct 20, 2016, at 3:56 AM, Eve Maler <eve@xmlgrrl.com <mailto: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?
Eve Maler Cell +1 425.345.6756 <tel:%2B1%20425.345.6756> | Skype: xmlgrrl | Twitter: @xmlgrrl
On Tue, Oct 18, 2016 at 2:01 PM, Cigdem Sengul <Cigdem.Sengul@nominet.uk <mailto: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.com <mailto:james.phillpotts@forgerock.com>> Date: Tuesday, 18 October 2016 at 13:32 To: Cigdem Sengul <Cigdem.Sengul@nominet.uk <mailto:Cigdem.Sengul@nominet.uk>> Cc: "wg-uma@kantarainitiative.org <mailto:wg-uma@kantarainitiative.org> WG" <wg-uma@kantarainitiative.org <mailto: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 <mailto: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 <mailto:WG-UMA@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/wg-uma <http://kantarainitiative.org/mailman/listinfo/wg-uma>
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org <mailto:WG-UMA@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/wg-uma <http://kantarainitiative.org/mailman/listinfo/wg-uma>
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org <mailto:WG-UMA@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/wg-uma <http://kantarainitiative.org/mailman/listinfo/wg-uma>
participants (4)
-
Cigdem Sengul -
Eve Maler -
James Phillpotts -
Justin Richer