Draft minutes of UMA telecon 2017-02-09
http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-02-09 MinutesRoll call Quorum was reached. Approve minutes Approve minutes of UMA telecon 2017-01-26 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-01-26> and 2017-02-02 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-02-02>: APPROVED. Logistics - No meeting Feb 16 because of RSAC - This week is our last scheduled 90-minute meeting; plans for Feb 23, Mar 2? Interest in ad hoc work Feb 21/22? - At RSAC, Kantara member/IDESG cocktail party on Thursday? No-host drinks somewhere? *AI:* Eve: Schedule 90-minute meetings out through Mar 2, and propose an ad hoc on Tuesday Feb 21, hopefully at the same bat time. *UMAnitarian no-host drinks get-together* at Salt House, 545 Mission St, Thursday evening, 6pm+! Drop Eve a line if you think you can make it, or dm or email her that day/evening. UMA V2.0 work Example doc for permission requests <https://docs.google.com/document/d/1jZ1Hua2jM5x4lcpN9URaAv9nGuP_d0hX54a_H5V8IW4/edit?usp=sharing>: We worked through this doc and had lots of conclusions. See that doc for spec instructions. Previous RPT: - Is this a super token? All rsid:scope <http://rsidscope/> tuples are continually added (and expired) - Is this a single token per RqP at the client? Does it also need to be bound to the RS? - Are super-token's a good idea? Do we want to promote them? - Motivation? - reduce coding complexity for the client? - reduce user experience complexity for the user? - i.e. the user doesn't have to keep providing the same claims over and over - Can we get the same behavior (improved user experience) for the user by using the PCT? - If we do want to keep the ability to add a previous RPT to a request, what is the effect on authorization assessment? - Does this effect change in the presence of a PCT on the request? James has weighed in in favor of a single RPT because of the burden, otherwise, on multi-user clients to manage potentially tens of millions of tokens without knowing which one works for which resource. A client can't provide multiple tokens to a resource to see which one works. If you want stateless tokens, you need to keep state in the token. It could be made efficient in various ways, but does it provide an incentive to go stateful instead? Even if the client provides a previous RPT, the AS still has the choice to hand the client a very session-specific token in response. There are various TTL strategies possible. What are the right strategies to simplify client developer logic? We keep dancing around informing the client more precisely what's in the token or what went on between the AS and RS. So far we haven't added anything to the UMA flow to do it. Another way to do it, potentially, is say: Client, if you have a way to introspect the token, go ahead. Is that tenable? (Justin's rant on OIDC's ID "tokens" not being tokens but rather assertions is somewhere in here <https://oauth.net/articles/authentication/>.) Revealing raw permission ticket contents doesn't seem smart because the client has no context to understand *requested* permissions if they go outside the access attempt. Could informing the client about *actually granted* scopes be a middle ground? If you pass in a previous RPT and the token was upgraded, you get an extra Boolean property in the response saying "yes, you were upgraded". If the property is empty, then the client knows it got a new one. In UMA1, the previous RPT had a role that sort of covered both client coding complexity (managing fewer tokens) and RqP experience complexity. In UMA2, now that clients can request scopes and AATs have been supplanted by PCTs, the previous RPT is meant for the former purpose and the PCT is meant for the latter. So how should authorization assessment be affected by both? *Spec instructions:* 1. The PCT, if present, is part of the claims and other information in evidence, as appropriate, in #2 (noting the temporal nature of this information and the opportunity to update it through claims collection). We already have language for this but *we probably need to add a warning about the possibility of out-of-date info getting updated*. 2. *After the assessment, if the result is to issue an RPT, and a previous RPT was on the request, and the AS decides to upgrade it, then add/merge the previous RPT with the CandidateGrantedScopes.* *Add guidance around the process of the AS deciding to issue upgraded tokens vs. not (the AS should pick one model vs. another), and the client having expectations of which one.* Attendees As of 19 Jan 2017 (post-meeting), quorum is 5 of 8. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem, Sarah) 1. Domenico 2. Sal 3. Maciej 4. Eve 5. Mike 6. Cigdem 7. Sarah Non-voting participants: - George - Justin - Thomas - Mohammad Regrets: - James *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
Justin, can you please propose something concrete around your notion of a flag in the AS response if it has upgraded the token? TIA! *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Thu, Feb 9, 2017 at 10:11 AM, Eve Maler <eve@xmlgrrl.com> wrote:
http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-02-09 MinutesRoll call
Quorum was reached. Approve minutes
Approve minutes of UMA telecon 2017-01-26 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-01-26> and 2017-02-02 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-02-02>: APPROVED. Logistics
- No meeting Feb 16 because of RSAC - This week is our last scheduled 90-minute meeting; plans for Feb 23, Mar 2? Interest in ad hoc work Feb 21/22? - At RSAC, Kantara member/IDESG cocktail party on Thursday? No-host drinks somewhere?
*AI:* Eve: Schedule 90-minute meetings out through Mar 2, and propose an ad hoc on Tuesday Feb 21, hopefully at the same bat time.
*UMAnitarian no-host drinks get-together* at Salt House, 545 Mission St, Thursday evening, 6pm+! Drop Eve a line if you think you can make it, or dm or email her that day/evening. UMA V2.0 work
Example doc for permission requests <https://docs.google.com/document/d/1jZ1Hua2jM5x4lcpN9URaAv9nGuP_d0hX54a_H5V8IW4/edit?usp=sharing>: We worked through this doc and had lots of conclusions. See that doc for spec instructions.
Previous RPT:
- Is this a super token? All rsid:scope <http://rsidscope/> tuples are continually added (and expired) - Is this a single token per RqP at the client? Does it also need to be bound to the RS? - Are super-token's a good idea? Do we want to promote them? - Motivation? - reduce coding complexity for the client? - reduce user experience complexity for the user? - i.e. the user doesn't have to keep providing the same claims over and over - Can we get the same behavior (improved user experience) for the user by using the PCT? - If we do want to keep the ability to add a previous RPT to a request, what is the effect on authorization assessment? - Does this effect change in the presence of a PCT on the request?
James has weighed in in favor of a single RPT because of the burden, otherwise, on multi-user clients to manage potentially tens of millions of tokens without knowing which one works for which resource. A client can't provide multiple tokens to a resource to see which one works.
If you want stateless tokens, you need to keep state in the token. It could be made efficient in various ways, but does it provide an incentive to go stateful instead? Even if the client provides a previous RPT, the AS still has the choice to hand the client a very session-specific token in response. There are various TTL strategies possible. What are the right strategies to simplify client developer logic? We keep dancing around informing the client more precisely what's in the token or what went on between the AS and RS. So far we haven't added anything to the UMA flow to do it. Another way to do it, potentially, is say: Client, if you have a way to introspect the token, go ahead. Is that tenable?
(Justin's rant on OIDC's ID "tokens" not being tokens but rather assertions is somewhere in here <https://oauth.net/articles/authentication/>.)
Revealing raw permission ticket contents doesn't seem smart because the client has no context to understand *requested* permissions if they go outside the access attempt. Could informing the client about *actually granted* scopes be a middle ground? If you pass in a previous RPT and the token was upgraded, you get an extra Boolean property in the response saying "yes, you were upgraded". If the property is empty, then the client knows it got a new one.
In UMA1, the previous RPT had a role that sort of covered both client coding complexity (managing fewer tokens) and RqP experience complexity. In UMA2, now that clients can request scopes and AATs have been supplanted by PCTs, the previous RPT is meant for the former purpose and the PCT is meant for the latter.
So how should authorization assessment be affected by both? *Spec instructions:*
1. The PCT, if present, is part of the claims and other information in evidence, as appropriate, in #2 (noting the temporal nature of this information and the opportunity to update it through claims collection). We already have language for this but *we probably need to add a warning about the possibility of out-of-date info getting updated*. 2. *After the assessment, if the result is to issue an RPT, and a previous RPT was on the request, and the AS decides to upgrade it, then add/merge the previous RPT with the CandidateGrantedScopes.*
*Add guidance around the process of the AS deciding to issue upgraded tokens vs. not (the AS should pick one model vs. another), and the client having expectations of which one.* Attendees
As of 19 Jan 2017 (post-meeting), quorum is 5 of 8. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem, Sarah)
1. Domenico 2. Sal 3. Maciej 4. Eve 5. Mike 6. Cigdem 7. Sarah
Non-voting participants:
- George - Justin - Thomas - Mohammad
Regrets:
- James
*Eve Maler*Cell +1 425.345.6756 <(425)%20345-6756> | Skype: xmlgrrl | Twitter: @xmlgrrl
The idea is simple. Extend the response from the token endpoint with the following element: upgraded: OPTIONAL Boolean value. If the Client submits an RPT in the token request and the AS includes the rights of the incoming RPT as part of the rights associated with the newly issued RPT, then this value MUST be set to "true". If the value is set to "false" or is absent, the client MUST act as if that the newly issued token does not include the rights associated with the RPT in the request. -- Justin On 2/9/2017 5:31 PM, Eve Maler wrote:
Justin, can you please propose something concrete around your notion of a flag in the AS response if it has upgraded the token? TIA!
*Eve Maler *Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
On Thu, Feb 9, 2017 at 10:11 AM, Eve Maler <eve@xmlgrrl.com <mailto:eve@xmlgrrl.com>> wrote:
http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-02-09 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-02-09>
Minutes
Roll call
Quorum was reached.
Approve minutes
Approve minutes of UMA telecon 2017-01-26 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-01-26> and 2017-02-02 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2017-02-02>: APPROVED.
Logistics
* No meeting Feb 16 because of RSAC * This week is our last scheduled 90-minute meeting; plans for Feb 23, Mar 2? Interest in ad hoc work Feb 21/22? * At RSAC, Kantara member/IDESG cocktail party on Thursday? No-host drinks somewhere?
*AI:* Eve: Schedule 90-minute meetings out through Mar 2, and propose an ad hoc on Tuesday Feb 21, hopefully at the same bat time.
*UMAnitarian no-host drinks get-together* at Salt House, 545 Mission St, Thursday evening, 6pm+! Drop Eve a line if you think you can make it, or dm or email her that day/evening.
UMA V2.0 work
Example doc for permission requests <https://docs.google.com/document/d/1jZ1Hua2jM5x4lcpN9URaAv9nGuP_d0hX54a_H5V8IW4/edit?usp=sharing>: We worked through this doc and had lots of conclusions. See that doc for spec instructions.
Previous RPT:
* Is this a super token? All rsid:scope <http://rsidscope/> tuples are continually added (and expired) * Is this a single token per RqP at the client? Does it also need to be bound to the RS? * Are super-token's a good idea? Do we want to promote them? * Motivation? o reduce coding complexity for the client? o reduce user experience complexity for the user? + i.e. the user doesn't have to keep providing the same claims over and over * Can we get the same behavior (improved user experience) for the user by using the PCT? * If we do want to keep the ability to add a previous RPT to a request, what is the effect on authorization assessment? * Does this effect change in the presence of a PCT on the request?
James has weighed in in favor of a single RPT because of the burden, otherwise, on multi-user clients to manage potentially tens of millions of tokens without knowing which one works for which resource. A client can't provide multiple tokens to a resource to see which one works.
If you want stateless tokens, you need to keep state in the token. It could be made efficient in various ways, but does it provide an incentive to go stateful instead? Even if the client provides a previous RPT, the AS still has the choice to hand the client a very session-specific token in response. There are various TTL strategies possible. What are the right strategies to simplify client developer logic? We keep dancing around informing the client more precisely what's in the token or what went on between the AS and RS. So far we haven't added anything to the UMA flow to do it. Another way to do it, potentially, is say: Client, if you have a way to introspect the token, go ahead. Is that tenable?
(Justin's rant on OIDC's ID "tokens" not being tokens but rather assertions is somewhere in here <https://oauth.net/articles/authentication/>.)
Revealing raw permission ticket contents doesn't seem smart because the client has no context to understand /requested/ permissions if they go outside the access attempt. Could informing the client about /actually granted/ scopes be a middle ground? If you pass in a previous RPT and the token was upgraded, you get an extra Boolean property in the response saying "yes, you were upgraded". If the property is empty, then the client knows it got a new one.
In UMA1, the previous RPT had a role that sort of covered both client coding complexity (managing fewer tokens) and RqP experience complexity. In UMA2, now that clients can request scopes and AATs have been supplanted by PCTs, the previous RPT is meant for the former purpose and the PCT is meant for the latter.
So how should authorization assessment be affected by both? *Spec instructions:*
1. The PCT, if present, is part of the claims and other information in evidence, as appropriate, in #2 (noting the temporal nature of this information and the opportunity to update it through claims collection). We already have language for this but *we probably need to add a warning about the possibility of out-of-date info getting updated*. 2. *After the assessment, if the result is to issue an RPT, and a previous RPT was on the request, and the AS decides to upgrade it, then add/merge the previous RPT with the /CandidateGrantedScopes/.*
*Add guidance around the process of the AS deciding to issue upgraded tokens vs. not (the AS should pick one model vs. another), and the client having expectations of which one.*
Attendees
As of 19 Jan 2017 (post-meeting), quorum is 5 of 8. (Domenico, Sal, Andi, Maciej, Eve, Mike, Cigdem, Sarah)
1. Domenico 2. Sal 3. Maciej 4. Eve 5. Mike 6. Cigdem 7. Sarah
Non-voting participants:
* George * Justin * Thomas * Mohammad
Regrets:
* James
*Eve Maler *Cell +1 425.345.6756 <tel:%28425%29%20345-6756> | Skype: xmlgrrl | Twitter: @xmlgrrl
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
participants (2)
-
Eve Maler -
Justin Richer