Notes from UMA telecon 2016-09-29
http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-09-29 MinutesRoll call Quorum was not reached. Approve minutes Approve minutes of UMA telecon 2016-09-22 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-09-22> : Deferred. Work on UMA.next issues We're wondering about the "authorization process" language in the new PCT definition. Instead of the three phases, we think a flowchart showing all of the AS responses to the client's request at the token endpoint (need_info and so on), and what the client has to do after that. E.g., if the client gets success and can then successfully access the resource, that's not "phase 3" but rather a successful singular termination of an "authorization process" and we should talk about it in that language. That's way more precise than just vaguely talking about "authorization process" without stating when such a thing starts and ends. The definition also needs to expand mentions of AS and so on, as we don't use the abbreviations in the spec. *AI:* Domenico and Eve: D to create a beautiful flow chart according to the current draft spec for slideware purposes and E to create an ASCII version for spec purposes. The current definition: "A correlation handle that represents a set of claims and interactions between the AS and the RqP/client pair during one authorization process to be used during future authorization processes. This MAY represent claims gathered interactively or pushed from the client. This MAY also represent any interactions the AS has with the RqP during this process, including any gathering of consent or authorization in any meaningful way. In short, this represents the sum total of the authorization process that a client went through to get its RPT (or even just trying to get its RPT). It’s intended to be used when this client gets a new RPT for this RqP at this AS, whether or not for the same resource or resource set and possibly for different policies or resource owners alltogether." A potential way to change it: "A correlation handle that represents a set of claims and interactions between the authorization server and the requesting party/client pair during one authorization process to be used during future authorization processes. This represents a set of claims and/or interactions; the authorization server MAY have gathered the claims interactively or the client MAY have pushed them, and an end-user requesting party MAY have provided consent or authorization in some fashion to the authorization server for persisting this information across authorization processes." Eve suggests moving the following text to Sec 1.3.2, where the conceptual explanation of the AAT used to be and where the conceptual explanation of the PCT kind of goes now: "The PCT represents the sum total of the authorization process that a client and its requesting part went through to obtain its RPT (or even just trying to get its RPT). It is intended to be used when this client obtain a new RPT for this requesting party at this authorization server, whether or not for the same resource set and possibly for different policies or resource owners." Looking at the name of the UMA grant, why "uma-ticket"? Is it because we have a "ticket pattern"? Okay. The PCT text in Sec 3.5.1 has us a bit confounded: "In circumstances where the authorization server returned an PCT previously when returning an RPT, the client MAY include the PCT. The PCT MAY have been obtained for a different resource at this AS, but since the PCT likely represents claims from the RqP it MUST be associated with the current RqP to the best of the client's abilities to determine this." Let's unpack this. In the OAuth-based AAT solution, authentication would have been required, and the client would known for a certainty whether it was the same RqP. Now, it doesn't know for sure. Plus, if it's requesting access to a different resource, the policies and therefore trust elevation requirements could be different; hence, whatever package of claims and/or interactions might be different. The client can't know a priori. But the PCT is meant to be associated with "the same RqP" as far as the client is concerned, regardless of whatever trust elevation is required on the AS side, and regardless of whatever the AS requires, don't all clients pretty much require some kind of authentication for their own purposes? So couldn't any client do correlation of PCTs with their own users with 100% certainty? *AI:* Eve: Get Justin's input on our analysis and questions. In Sec 3.5.2, the first appearance of set math is hinted at: "The authorization server evaluates the policies in light of claims gathered from the client. These claims MAY be pushed directly by the client using the claim_tokens parameter, MAY be gathered interactively at the interactive claims gathering endpoint, and MAY be *represnted* by the persisted claims token (PCT) present by the client in the pct *paramter*. The authorization server MAY combine claims from these sources in any manner it chooses, though a simple union of all claims is reasonable." (Note and fix typos.) James had proposed set math as follows: (ASDefaultClientScopes UNION ClientRequestScopes UNION PermissionTicketScopes) SUPER_SET_OR_EQUAL_TO PermissionTicketScopes The questions for the spec are: - What does the RS have to do at API publication time, if anything? - There *will* be scopes published, whether in informal fashion or, say, Swagger (machine-readable) - Nothing much more to say about this, probably (we have some editorial notes on it) - What does the client have to do at scope registration time, if anything? - It's never required for a client to register for scopes, but it could; this would limit what's possible for it to handle (we have some editorial notes on it) - *What does the RS have to do at permission ticket registration time?* - In UMA1, we've said it must register at least what the client attempted to access, but Justin has proposed letting it register any number of scopes, more/less/other - This remains to be fully discussed, though we started it at CIS - *Can the client request scopes from the RS (in addition to just attempting access)?* (added after the call: see George's comments from 2016-08-04 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-08-04> about efficiency of client communications for smart clients) - What does the client have to do at RPT request time? - *How does the client request scopes from the AS, and what can it ask for (e.g., what interaction does it have if it wants multiple resource sets)?* - In UMA1, the client couldn't ask for anything explicitly, but Justin's MPD exploration has made it possible (though not required) for the client to request scopes and we've agreed to make this possible - What does the AS have to do at RPT issuance time? - In UMA1, we've said the AS can issue a partial set of scopes if policy is only partially satisfied – are we still okay with that? We haven't discussed it - There are circumstances where only full matching will do (say, enterprise), and others where partial satisfaction would be good (consumer) Spec instructions: - See above! Attendees As of 31 Aug 2016, quorum is 6 of 10. (Domenico, Sal, Nagesh, Andi, Robert, Maciej, Eve, Jeffrey, Mike, Sarah) 1. Domenico 2. Sal 3. Nagesh 4. Robert 5. Eve Non-voting participants: - Andrew - Scott F - Kathleen - James Regrets: - Mike - John W - Andi *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
A note on this comment: Let's unpack this. In the OAuth-based AAT solution, authentication would have been required, and the client would known for a certainty whether it was the same RqP. Now, it doesn't know for sure. Plus, if it's requesting access to a different resource, the policies and therefore trust elevation requirements could be different; hence, whatever package of claims and/or interactions might be different. The client can't know a priori. But the PCT is meant to be associated with "the same RqP" as far as the client is concerned, regardless of whatever trust elevation is required on the AS side, and regardless of whatever the AS requires, don't all clients pretty much require some kind of authentication for their own purposes? So couldn't any client do correlation of PCTs with their own users with 100% certainty? The AAT doesn’t tell the client who the RqP is any more than any other OAuth access token does. The AAT represents an authenticated user at the AS, but not at the client. The PCT might represent authentication or any number of other things at the AS, but again not at the client. With an AAT, that means making sure you use the right AAT for the current RqP. With the PCT, the same condition applies: you only present the PCT associated with this RqP (and the claims the PCT represents). In both cases, it’s up to a multi-user client to manage its relationship with the RqP, and it’ll do so however it best sees fit. The client could do this binding to the “current RqP" on its side through authentication, or assuming it’s a single-user program (like a mobile app), or any number of other session management mechanisms. It’s not up to UMA to decide how it happens, but UMA does depend on it in exactly the same way that OAuth doesn’t say a word about how the client manages its connection to the RO, but depends on the client managing that connection. So in the end, it’s exactly the same requirement and assumptions as before: before the client sends a token that ostensibly represents the RqP (either the AAT or PCT), it needs to be sure it’s sending the right token for the right RqP. The only difference here is that we’re explicitly spelling it out as a requirement instead of leaving it as implicit. I couldn’t find specific text in the OAuth RFCs dealing with this, but maybe someone else will have better luck searching. Hope this clears things up on that point. Also, note that the set math around the claims (from the PCT, pushed by client, and gathered interactively) is completely separate from and orthogonal to the set math around the scopes. Be careful not to conflate the two! — Justin
On Sep 29, 2016, at 4:24 PM, Eve Maler <eve@xmlgrrl.com> wrote:
http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-09-29 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-09-29> Minutes Roll call Quorum was not reached. Approve minutes Approve minutes of UMA telecon 2016-09-22 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-09-22> : Deferred. Work on UMA.next issues We're wondering about the "authorization process" language in the new PCT definition. Instead of the three phases, we think a flowchart showing all of the AS responses to the client's request at the token endpoint (need_info and so on), and what the client has to do after that. E.g., if the client gets success and can then successfully access the resource, that's not "phase 3" but rather a successful singular termination of an "authorization process" and we should talk about it in that language. That's way more precise than just vaguely talking about "authorization process" without stating when such a thing starts and ends. The definition also needs to expand mentions of AS and so on, as we don't use the abbreviations in the spec. AI: Domenico and Eve: D to create a beautiful flow chart according to the current draft spec for slideware purposes and E to create an ASCII version for spec purposes. The current definition: "A correlation handle that represents a set of claims and interactions between the AS and the RqP/client pair during one authorization process to be used during future authorization processes. This MAY represent claims gathered interactively or pushed from the client. This MAY also represent any interactions the AS has with the RqP during this process, including any gathering of consent or authorization in any meaningful way. In short, this represents the sum total of the authorization process that a client went through to get its RPT (or even just trying to get its RPT). It’s intended to be used when this client gets a new RPT for this RqP at this AS, whether or not for the same resource or resource set and possibly for different policies or resource owners alltogether." A potential way to change it: "A correlation handle that represents a set of claims and interactions between the authorization server and the requesting party/client pair during one authorization process to be used during future authorization processes. This represents a set of claims and/or interactions; the authorization server MAY have gathered the claims interactively or the client MAY have pushed them, and an end-user requesting party MAY have provided consent or authorization in some fashion to the authorization server for persisting this information across authorization processes." Eve suggests moving the following text to Sec 1.3.2, where the conceptual explanation of the AAT used to be and where the conceptual explanation of the PCT kind of goes now: "The PCT represents the sum total of the authorization process that a client and its requesting part went through to obtain its RPT (or even just trying to get its RPT). It is intended to be used when this client obtain a new RPT for this requesting party at this authorization server, whether or not for the same resource set and possibly for different policies or resource owners." Looking at the name of the UMA grant, why "uma-ticket"? Is it because we have a "ticket pattern"? Okay. The PCT text in Sec 3.5.1 has us a bit confounded: "In circumstances where the authorization server returned an PCT previously when returning an RPT, the client MAY include the PCT. The PCT MAY have been obtained for a different resource at this AS, but since the PCT likely represents claims from the RqP it MUST be associated with the current RqP to the best of the client's abilities to determine this." Let's unpack this. In the OAuth-based AAT solution, authentication would have been required, and the client would known for a certainty whether it was the same RqP. Now, it doesn't know for sure. Plus, if it's requesting access to a different resource, the policies and therefore trust elevation requirements could be different; hence, whatever package of claims and/or interactions might be different. The client can't know a priori. But the PCT is meant to be associated with "the same RqP" as far as the client is concerned, regardless of whatever trust elevation is required on the AS side, and regardless of whatever the AS requires, don't all clients pretty much require some kind of authentication for their own purposes? So couldn't any client do correlation of PCTs with their own users with 100% certainty? AI: Eve: Get Justin's input on our analysis and questions. In Sec 3.5.2, the first appearance of set math is hinted at: "The authorization server evaluates the policies in light of claims gathered from the client. These claims MAY be pushed directly by the client using the claim_tokens parameter, MAY be gathered interactively at the interactive claims gathering endpoint, and MAY be represnted by the persisted claims token (PCT) present by the client in the pct paramter. The authorization server MAY combine claims from these sources in any manner it chooses, though a simple union of all claims is reasonable." (Note and fix typos.) James had proposed set math as follows: (ASDefaultClientScopes UNION ClientRequestScopes UNION PermissionTicketScopes) SUPER_SET_OR_EQUAL_TO PermissionTicketScopes The questions for the spec are: What does the RS have to do at API publication time, if anything? There will be scopes published, whether in informal fashion or, say, Swagger (machine-readable) Nothing much more to say about this, probably (we have some editorial notes on it) What does the client have to do at scope registration time, if anything? It's never required for a client to register for scopes, but it could; this would limit what's possible for it to handle (we have some editorial notes on it) What does the RS have to do at permission ticket registration time? In UMA1, we've said it must register at least what the client attempted to access, but Justin has proposed letting it register any number of scopes, more/less/other This remains to be fully discussed, though we started it at CIS Can the client request scopes from the RS (in addition to just attempting access)? (added after the call: see George's comments from 2016-08-04 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-08-04> about efficiency of client communications for smart clients) What does the client have to do at RPT request time? How does the client request scopes from the AS, and what can it ask for (e.g., what interaction does it have if it wants multiple resource sets)? In UMA1, the client couldn't ask for anything explicitly, but Justin's MPD exploration has made it possible (though not required) for the client to request scopes and we've agreed to make this possible What does the AS have to do at RPT issuance time? In UMA1, we've said the AS can issue a partial set of scopes if policy is only partially satisfied – are we still okay with that? We haven't discussed it There are circumstances where only full matching will do (say, enterprise), and others where partial satisfaction would be good (consumer) Spec instructions: See above! Attendees As of 31 Aug 2016, quorum is 6 of 10. (Domenico, Sal, Nagesh, Andi, Robert, Maciej, Eve, Jeffrey, Mike, Sarah) Domenico Sal Nagesh Robert Eve Non-voting participants: Andrew Scott F Kathleen James Regrets: Mike John W Andi
Eve Maler Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
Regarding "math" of claims vs. scopes: Yes, of course, you're right, I think I got overexcited seeing we were getting near policy-matching. :-) In any case, I think we're close to getting back onto that topic. Do we actually need to be saying "The authorization server MAY combine claims from these sources in any manner it chooses, though a simple union of all claims is reasonable."? On the one hand, what would happen if we said nothing (since the statement is non-testable)? On the other hand, what if someone wanted to create an extension trust elevation mechanism that added logical operators for claims gathering, indicating that some were optional and, if supplied, could be used at will or something? ==== Regarding this text -- "The PCT MAY have been obtained for a different resource at this AS, but since the PCT likely represents claims from the RqP it MUST be associated with the current RqP to the best of the client's abilities to determine this." -- and the question of RqP matching: So I think you're saying this was true before with AATs but we provided no guidance about it. And the reason you're mentioning different resources is because if it were the same resource, it would be more obviously the same RqP? I feel like there's some leap being made there that I'm not quite grasping. Even if an attempt at access were being made to the "same resource" (a resource that had been accessed before by this client that had been handed a PCT and RPT, a PCT and RPT it is attempting to wield now), the client had better have done a good job of "RqP-matching" just as you're describing. I think. Should we be saying something more like this? "If a client intends to use an issued PCT in a subsequent authorization process to represent the same requesting party, it MUST associate that PCT with its own persisted representation of that requesting party to the best of its ability." *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Thu, Sep 29, 2016 at 2:43 PM, Justin Richer <jricher@mit.edu> wrote:
A note on this comment:
Let's unpack this. In the OAuth-based AAT solution, authentication would have been required, and the client would known for a certainty whether it was the same RqP. Now, it doesn't know for sure. Plus, if it's requesting access to a different resource, the policies and therefore trust elevation requirements could be different; hence, whatever package of claims and/or interactions might be different. The client can't know a priori. But the PCT is meant to be associated with "the same RqP" as far as the client is concerned, regardless of whatever trust elevation is required on the AS side, and regardless of whatever the AS requires, don't all clients pretty much require some kind of authentication for their own purposes? So couldn't any client do correlation of PCTs with their own users with 100% certainty?
The AAT doesn’t tell the client who the RqP is any more than any other OAuth access token does. The AAT represents an authenticated user at the AS, but not at the client. The PCT might represent authentication or any number of other things at the AS, but again not at the client. With an AAT, that means making sure you use the right AAT for the current RqP. With the PCT, the same condition applies: you only present the PCT associated with this RqP (and the claims the PCT represents). In both cases, it’s up to a multi-user client to manage its relationship with the RqP, and it’ll do so however it best sees fit. The client could do this binding to the “current RqP" on its side through authentication, or assuming it’s a single-user program (like a mobile app), or any number of other session management mechanisms. It’s not up to UMA to decide how it happens, but UMA does depend on it in exactly the same way that OAuth doesn’t say a word about how the client manages its connection to the RO, but depends on the client managing that connection.
So in the end, it’s exactly the same requirement and assumptions as before: before the client sends a token that ostensibly represents the RqP (either the AAT or PCT), it needs to be sure it’s sending the right token for the right RqP. The only difference here is that we’re explicitly spelling it out as a requirement instead of leaving it as implicit. I couldn’t find specific text in the OAuth RFCs dealing with this, but maybe someone else will have better luck searching.
Hope this clears things up on that point.
Also, note that the set math around the claims (from the PCT, pushed by client, and gathered interactively) is completely separate from and orthogonal to the set math around the scopes. Be careful not to conflate the two!
— Justin
On Sep 29, 2016, at 4:24 PM, Eve Maler <eve@xmlgrrl.com> wrote:
http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-09-29 MinutesRoll call
Quorum was not reached. Approve minutes
Approve minutes of UMA telecon 2016-09-22 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-09-22> : Deferred. Work on UMA.next issues
We're wondering about the "authorization process" language in the new PCT definition. Instead of the three phases, we think a flowchart showing all of the AS responses to the client's request at the token endpoint (need_info and so on), and what the client has to do after that. E.g., if the client gets success and can then successfully access the resource, that's not "phase 3" but rather a successful singular termination of an "authorization process" and we should talk about it in that language. That's way more precise than just vaguely talking about "authorization process" without stating when such a thing starts and ends.
The definition also needs to expand mentions of AS and so on, as we don't use the abbreviations in the spec.
*AI:* Domenico and Eve: D to create a beautiful flow chart according to the current draft spec for slideware purposes and E to create an ASCII version for spec purposes.
The current definition: "A correlation handle that represents a set of claims and interactions between the AS and the RqP/client pair during one authorization process to be used during future authorization processes. This MAY represent claims gathered interactively or pushed from the client. This MAY also represent any interactions the AS has with the RqP during this process, including any gathering of consent or authorization in any meaningful way. In short, this represents the sum total of the authorization process that a client went through to get its RPT (or even just trying to get its RPT). It’s intended to be used when this client gets a new RPT for this RqP at this AS, whether or not for the same resource or resource set and possibly for different policies or resource owners alltogether."
A potential way to change it: "A correlation handle that represents a set of claims and interactions between the authorization server and the requesting party/client pair during one authorization process to be used during future authorization processes. This represents a set of claims and/or interactions; the authorization server MAY have gathered the claims interactively or the client MAY have pushed them, and an end-user requesting party MAY have provided consent or authorization in some fashion to the authorization server for persisting this information across authorization processes."
Eve suggests moving the following text to Sec 1.3.2, where the conceptual explanation of the AAT used to be and where the conceptual explanation of the PCT kind of goes now: "The PCT represents the sum total of the authorization process that a client and its requesting part went through to obtain its RPT (or even just trying to get its RPT). It is intended to be used when this client obtain a new RPT for this requesting party at this authorization server, whether or not for the same resource set and possibly for different policies or resource owners."
Looking at the name of the UMA grant, why "uma-ticket"? Is it because we have a "ticket pattern"? Okay.
The PCT text in Sec 3.5.1 has us a bit confounded: "In circumstances where the authorization server returned an PCT previously when returning an RPT, the client MAY include the PCT. The PCT MAY have been obtained for a different resource at this AS, but since the PCT likely represents claims from the RqP it MUST be associated with the current RqP to the best of the client's abilities to determine this."
Let's unpack this. In the OAuth-based AAT solution, authentication would have been required, and the client would known for a certainty whether it was the same RqP. Now, it doesn't know for sure. Plus, if it's requesting access to a different resource, the policies and therefore trust elevation requirements could be different; hence, whatever package of claims and/or interactions might be different. The client can't know a priori. But the PCT is meant to be associated with "the same RqP" as far as the client is concerned, regardless of whatever trust elevation is required on the AS side, and regardless of whatever the AS requires, don't all clients pretty much require some kind of authentication for their own purposes? So couldn't any client do correlation of PCTs with their own users with 100% certainty?
*AI:* Eve: Get Justin's input on our analysis and questions.
In Sec 3.5.2, the first appearance of set math is hinted at: "The authorization server evaluates the policies in light of claims gathered from the client. These claims MAY be pushed directly by the client using the claim_tokens parameter, MAY be gathered interactively at the interactive claims gathering endpoint, and MAY be *represnted* by the persisted claims token (PCT) present by the client in the pct *paramter*. The authorization server MAY combine claims from these sources in any manner it chooses, though a simple union of all claims is reasonable."
(Note and fix typos.)
James had proposed set math as follows:
(ASDefaultClientScopes UNION ClientRequestScopes UNION PermissionTicketScopes) SUPER_SET_OR_EQUAL_TO PermissionTicketScopes
The questions for the spec are:
- What does the RS have to do at API publication time, if anything? - There *will* be scopes published, whether in informal fashion or, say, Swagger (machine-readable) - Nothing much more to say about this, probably (we have some editorial notes on it) - What does the client have to do at scope registration time, if anything? - It's never required for a client to register for scopes, but it could; this would limit what's possible for it to handle (we have some editorial notes on it) - *What does the RS have to do at permission ticket registration time?* - In UMA1, we've said it must register at least what the client attempted to access, but Justin has proposed letting it register any number of scopes, more/less/other - This remains to be fully discussed, though we started it at CIS - *Can the client request scopes from the RS (in addition to just attempting access)?* (added after the call: see George's comments from 2016-08-04 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-08-04> about efficiency of client communications for smart clients) - What does the client have to do at RPT request time? - *How does the client request scopes from the AS, and what can it ask for (e.g., what interaction does it have if it wants multiple resource sets)?* - In UMA1, the client couldn't ask for anything explicitly, but Justin's MPD exploration has made it possible (though not required) for the client to request scopes and we've agreed to make this possible - What does the AS have to do at RPT issuance time? - In UMA1, we've said the AS can issue a partial set of scopes if policy is only partially satisfied – are we still okay with that? We haven't discussed it - There are circumstances where only full matching will do (say, enterprise), and others where partial satisfaction would be good (consumer)
Spec instructions:
- See above!
Attendees
As of 31 Aug 2016, quorum is 6 of 10. (Domenico, Sal, Nagesh, Andi, Robert, Maciej, Eve, Jeffrey, Mike, Sarah)
1. Domenico 2. Sal 3. Nagesh 4. Robert 5. Eve
Non-voting participants:
- Andrew - Scott F - Kathleen - James
Regrets:
- Mike - John W - Andi
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
On Sep 29, 2016, at 11:32 PM, Eve Maler <eve@xmlgrrl.com> wrote:
Regarding "math" of claims vs. scopes: Yes, of course, you're right, I think I got overexcited seeing we were getting near policy-matching. :-) In any case, I think we're close to getting back onto that topic.
Do we actually need to be saying "The authorization server MAY combine claims from these sources in any manner it chooses, though a simple union of all claims is reasonable."? On the one hand, what would happen if we said nothing (since the statement is non-testable)? On the other hand, what if someone wanted to create an extension trust elevation mechanism that added logical operators for claims gathering, indicating that some were optional and, if supplied, could be used at will or something?
Possibly needs to be more robust like that. I erred on the side of simplicity and based on my implementation: just smash all the things together. I think at the very least guidance to developers is a good idea otherwise we’re going to get mismatched expectations from clients presenting PCTs.
====
Regarding this text -- "The PCT MAY have been obtained for a different resource at this AS, but since the PCT likely represents claims from the RqP it MUST be associated with the current RqP to the best of the client's abilities to determine this." -- and the question of RqP matching:
So I think you're saying this was true before with AATs but we provided no guidance about it.
Correct.
And the reason you're mentioning different resources is because if it were the same resource, it would be more obviously the same RqP?
Possibly. Could be two RqPs using the same client to get the same resource, in which case it should be separate RPTs and separate PCTs. The same way an OAuth client getting a resource for two RO’s would get two access tokens and keep them separately tied to user sessions.
I feel like there's some leap being made there that I'm not quite grasping. Even if an attempt at access were being made to the "same resource" (a resource that had been accessed before by this client that had been handed a PCT and RPT, a PCT and RPT it is attempting to wield now), the client had better have done a good job of "RqP-matching" just as you're describing. I think.
Correct. What’s the leap? The requirement to match the PCT to the RqP is universal, but the PCT MAY have come from a different resource. Perhaps the sentence order should be swapped — were you reading the former part as a conditional? That’s not the intended interpretation.
Should we be saying something more like this? "If a client intends to use an issued PCT in a subsequent authorization process to represent the same requesting party, it MUST associate that PCT with its own persisted representation of that requesting party to the best of its ability.”
Something like that, avoiding “persisted representation” and other leading language of course. — Justin
Eve Maler Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
On Thu, Sep 29, 2016 at 2:43 PM, Justin Richer <jricher@mit.edu <mailto:jricher@mit.edu>> wrote: A note on this comment:
Let's unpack this. In the OAuth-based AAT solution, authentication would have been required, and the client would known for a certainty whether it was the same RqP. Now, it doesn't know for sure. Plus, if it's requesting access to a different resource, the policies and therefore trust elevation requirements could be different; hence, whatever package of claims and/or interactions might be different. The client can't know a priori. But the PCT is meant to be associated with "the same RqP" as far as the client is concerned, regardless of whatever trust elevation is required on the AS side, and regardless of whatever the AS requires, don't all clients pretty much require some kind of authentication for their own purposes? So couldn't any client do correlation of PCTs with their own users with 100% certainty?
The AAT doesn’t tell the client who the RqP is any more than any other OAuth access token does. The AAT represents an authenticated user at the AS, but not at the client. The PCT might represent authentication or any number of other things at the AS, but again not at the client. With an AAT, that means making sure you use the right AAT for the current RqP. With the PCT, the same condition applies: you only present the PCT associated with this RqP (and the claims the PCT represents). In both cases, it’s up to a multi-user client to manage its relationship with the RqP, and it’ll do so however it best sees fit. The client could do this binding to the “current RqP" on its side through authentication, or assuming it’s a single-user program (like a mobile app), or any number of other session management mechanisms. It’s not up to UMA to decide how it happens, but UMA does depend on it in exactly the same way that OAuth doesn’t say a word about how the client manages its connection to the RO, but depends on the client managing that connection.
So in the end, it’s exactly the same requirement and assumptions as before: before the client sends a token that ostensibly represents the RqP (either the AAT or PCT), it needs to be sure it’s sending the right token for the right RqP. The only difference here is that we’re explicitly spelling it out as a requirement instead of leaving it as implicit. I couldn’t find specific text in the OAuth RFCs dealing with this, but maybe someone else will have better luck searching.
Hope this clears things up on that point.
Also, note that the set math around the claims (from the PCT, pushed by client, and gathered interactively) is completely separate from and orthogonal to the set math around the scopes. Be careful not to conflate the two!
— Justin
On Sep 29, 2016, at 4:24 PM, Eve Maler <eve@xmlgrrl.com <mailto:eve@xmlgrrl.com>> wrote:
http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-09-29 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-09-29> Minutes Roll call Quorum was not reached. Approve minutes Approve minutes of UMA telecon 2016-09-22 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-09-22> : Deferred. Work on UMA.next issues We're wondering about the "authorization process" language in the new PCT definition. Instead of the three phases, we think a flowchart showing all of the AS responses to the client's request at the token endpoint (need_info and so on), and what the client has to do after that. E.g., if the client gets success and can then successfully access the resource, that's not "phase 3" but rather a successful singular termination of an "authorization process" and we should talk about it in that language. That's way more precise than just vaguely talking about "authorization process" without stating when such a thing starts and ends. The definition also needs to expand mentions of AS and so on, as we don't use the abbreviations in the spec. AI: Domenico and Eve: D to create a beautiful flow chart according to the current draft spec for slideware purposes and E to create an ASCII version for spec purposes. The current definition: "A correlation handle that represents a set of claims and interactions between the AS and the RqP/client pair during one authorization process to be used during future authorization processes. This MAY represent claims gathered interactively or pushed from the client. This MAY also represent any interactions the AS has with the RqP during this process, including any gathering of consent or authorization in any meaningful way. In short, this represents the sum total of the authorization process that a client went through to get its RPT (or even just trying to get its RPT). It’s intended to be used when this client gets a new RPT for this RqP at this AS, whether or not for the same resource or resource set and possibly for different policies or resource owners alltogether." A potential way to change it: "A correlation handle that represents a set of claims and interactions between the authorization server and the requesting party/client pair during one authorization process to be used during future authorization processes. This represents a set of claims and/or interactions; the authorization server MAY have gathered the claims interactively or the client MAY have pushed them, and an end-user requesting party MAY have provided consent or authorization in some fashion to the authorization server for persisting this information across authorization processes." Eve suggests moving the following text to Sec 1.3.2, where the conceptual explanation of the AAT used to be and where the conceptual explanation of the PCT kind of goes now: "The PCT represents the sum total of the authorization process that a client and its requesting part went through to obtain its RPT (or even just trying to get its RPT). It is intended to be used when this client obtain a new RPT for this requesting party at this authorization server, whether or not for the same resource set and possibly for different policies or resource owners." Looking at the name of the UMA grant, why "uma-ticket"? Is it because we have a "ticket pattern"? Okay. The PCT text in Sec 3.5.1 has us a bit confounded: "In circumstances where the authorization server returned an PCT previously when returning an RPT, the client MAY include the PCT. The PCT MAY have been obtained for a different resource at this AS, but since the PCT likely represents claims from the RqP it MUST be associated with the current RqP to the best of the client's abilities to determine this." Let's unpack this. In the OAuth-based AAT solution, authentication would have been required, and the client would known for a certainty whether it was the same RqP. Now, it doesn't know for sure. Plus, if it's requesting access to a different resource, the policies and therefore trust elevation requirements could be different; hence, whatever package of claims and/or interactions might be different. The client can't know a priori. But the PCT is meant to be associated with "the same RqP" as far as the client is concerned, regardless of whatever trust elevation is required on the AS side, and regardless of whatever the AS requires, don't all clients pretty much require some kind of authentication for their own purposes? So couldn't any client do correlation of PCTs with their own users with 100% certainty? AI: Eve: Get Justin's input on our analysis and questions. In Sec 3.5.2, the first appearance of set math is hinted at: "The authorization server evaluates the policies in light of claims gathered from the client. These claims MAY be pushed directly by the client using the claim_tokens parameter, MAY be gathered interactively at the interactive claims gathering endpoint, and MAY be represnted by the persisted claims token (PCT) present by the client in the pct paramter. The authorization server MAY combine claims from these sources in any manner it chooses, though a simple union of all claims is reasonable." (Note and fix typos.) James had proposed set math as follows: (ASDefaultClientScopes UNION ClientRequestScopes UNION PermissionTicketScopes) SUPER_SET_OR_EQUAL_TO PermissionTicketScopes The questions for the spec are: What does the RS have to do at API publication time, if anything? There will be scopes published, whether in informal fashion or, say, Swagger (machine-readable) Nothing much more to say about this, probably (we have some editorial notes on it) What does the client have to do at scope registration time, if anything? It's never required for a client to register for scopes, but it could; this would limit what's possible for it to handle (we have some editorial notes on it) What does the RS have to do at permission ticket registration time? In UMA1, we've said it must register at least what the client attempted to access, but Justin has proposed letting it register any number of scopes, more/less/other This remains to be fully discussed, though we started it at CIS Can the client request scopes from the RS (in addition to just attempting access)? (added after the call: see George's comments from 2016-08-04 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-08-04> about efficiency of client communications for smart clients) What does the client have to do at RPT request time? How does the client request scopes from the AS, and what can it ask for (e.g., what interaction does it have if it wants multiple resource sets)? In UMA1, the client couldn't ask for anything explicitly, but Justin's MPD exploration has made it possible (though not required) for the client to request scopes and we've agreed to make this possible What does the AS have to do at RPT issuance time? In UMA1, we've said the AS can issue a partial set of scopes if policy is only partially satisfied – are we still okay with that? We haven't discussed it There are circumstances where only full matching will do (say, enterprise), and others where partial satisfaction would be good (consumer) Spec instructions: See above! Attendees As of 31 Aug 2016, quorum is 6 of 10. (Domenico, Sal, Nagesh, Andi, Robert, Maciej, Eve, Jeffrey, Mike, Sarah) Domenico Sal Nagesh Robert Eve Non-voting participants: Andrew Scott F Kathleen James Regrets: Mike John W Andi
Eve Maler Cell +1 425.345.6756 <tel:%2B1%20425.345.6756> | Skype: xmlgrrl | Twitter: @xmlgrrl
_______________________________________________ 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>
Regarding claim combining, the more I think about it, I don't think we can really say too much. Claims (in band) are one thing and policy conditions (out of band) are another. Any claims collected are, I think, just pieces of information in a flat space as far as UMA's "native claims data model" is concerned (so maybe we could go as far as saying that, while maybe pointing off to the extensibility section if you want to do more). On the other hand, policy expression models and engines could be arbitrarily sophisticated in what they do with that information: You have to be A, and not-B, and can optionally be C, and so on. ==== Regarding PCT care and feeding on the client side, I had been figuring that "persisted representation" of its user was at the heart of it, not leading language. I'm still not getting why the PCT having been issued on a visit to a different resource is so key. What if it were a visit to the same resource whose operative policies had changed or something? The *really* important thing is: What if the client goes back to the *identical* resource but the client is being wielded by a *different* RqP this time? What is the client's responsibility and how should it handle it? *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Fri, Sep 30, 2016 at 6:21 AM, Justin Richer <jricher@mit.edu> wrote:
On Sep 29, 2016, at 11:32 PM, Eve Maler <eve@xmlgrrl.com> wrote:
Regarding "math" of claims vs. scopes: Yes, of course, you're right, I think I got overexcited seeing we were getting near policy-matching. :-) In any case, I think we're close to getting back onto that topic.
Do we actually need to be saying "The authorization server MAY combine claims from these sources in any manner it chooses, though a simple union of all claims is reasonable."? On the one hand, what would happen if we said nothing (since the statement is non-testable)? On the other hand, what if someone wanted to create an extension trust elevation mechanism that added logical operators for claims gathering, indicating that some were optional and, if supplied, could be used at will or something?
Possibly needs to be more robust like that. I erred on the side of simplicity and based on my implementation: just smash all the things together. I think at the very least guidance to developers is a good idea otherwise we’re going to get mismatched expectations from clients presenting PCTs.
====
Regarding this text -- "The PCT MAY have been obtained for a different resource at this AS, but since the PCT likely represents claims from the RqP it MUST be associated with the current RqP to the best of the client's abilities to determine this." -- and the question of RqP matching:
So I think you're saying this was true before with AATs but we provided no guidance about it.
Correct.
And the reason you're mentioning different resources is because if it were the same resource, it would be more obviously the same RqP?
Possibly. Could be two RqPs using the same client to get the same resource, in which case it should be separate RPTs and separate PCTs. The same way an OAuth client getting a resource for two RO’s would get two access tokens and keep them separately tied to user sessions.
I feel like there's some leap being made there that I'm not quite grasping. Even if an attempt at access were being made to the "same resource" (a resource that had been accessed before by this client that had been handed a PCT and RPT, a PCT and RPT it is attempting to wield now), the client had better have done a good job of "RqP-matching" just as you're describing. I think.
Correct. What’s the leap? The requirement to match the PCT to the RqP is universal, but the PCT MAY have come from a different resource. Perhaps the sentence order should be swapped — were you reading the former part as a conditional? That’s not the intended interpretation.
Should we be saying something more like this? "If a client intends to use an issued PCT in a subsequent authorization process to represent the same requesting party, it MUST associate that PCT with its own persisted representation of that requesting party to the best of its ability.”
Something like that, avoiding “persisted representation” and other leading language of course.
— Justin
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
On Thu, Sep 29, 2016 at 2:43 PM, Justin Richer <jricher@mit.edu> wrote:
A note on this comment:
Let's unpack this. In the OAuth-based AAT solution, authentication would have been required, and the client would known for a certainty whether it was the same RqP. Now, it doesn't know for sure. Plus, if it's requesting access to a different resource, the policies and therefore trust elevation requirements could be different; hence, whatever package of claims and/or interactions might be different. The client can't know a priori. But the PCT is meant to be associated with "the same RqP" as far as the client is concerned, regardless of whatever trust elevation is required on the AS side, and regardless of whatever the AS requires, don't all clients pretty much require some kind of authentication for their own purposes? So couldn't any client do correlation of PCTs with their own users with 100% certainty?
The AAT doesn’t tell the client who the RqP is any more than any other OAuth access token does. The AAT represents an authenticated user at the AS, but not at the client. The PCT might represent authentication or any number of other things at the AS, but again not at the client. With an AAT, that means making sure you use the right AAT for the current RqP. With the PCT, the same condition applies: you only present the PCT associated with this RqP (and the claims the PCT represents). In both cases, it’s up to a multi-user client to manage its relationship with the RqP, and it’ll do so however it best sees fit. The client could do this binding to the “current RqP" on its side through authentication, or assuming it’s a single-user program (like a mobile app), or any number of other session management mechanisms. It’s not up to UMA to decide how it happens, but UMA does depend on it in exactly the same way that OAuth doesn’t say a word about how the client manages its connection to the RO, but depends on the client managing that connection.
So in the end, it’s exactly the same requirement and assumptions as before: before the client sends a token that ostensibly represents the RqP (either the AAT or PCT), it needs to be sure it’s sending the right token for the right RqP. The only difference here is that we’re explicitly spelling it out as a requirement instead of leaving it as implicit. I couldn’t find specific text in the OAuth RFCs dealing with this, but maybe someone else will have better luck searching.
Hope this clears things up on that point.
Also, note that the set math around the claims (from the PCT, pushed by client, and gathered interactively) is completely separate from and orthogonal to the set math around the scopes. Be careful not to conflate the two!
— Justin
On Sep 29, 2016, at 4:24 PM, Eve Maler <eve@xmlgrrl.com> wrote:
http://kantarainitiative.org/confluence/display/uma/UMA+tele con+2016-09-29 MinutesRoll call
Quorum was not reached. Approve minutes
Approve minutes of UMA telecon 2016-09-22 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-09-22> : Deferred. Work on UMA.next issues
We're wondering about the "authorization process" language in the new PCT definition. Instead of the three phases, we think a flowchart showing all of the AS responses to the client's request at the token endpoint (need_info and so on), and what the client has to do after that. E.g., if the client gets success and can then successfully access the resource, that's not "phase 3" but rather a successful singular termination of an "authorization process" and we should talk about it in that language. That's way more precise than just vaguely talking about "authorization process" without stating when such a thing starts and ends.
The definition also needs to expand mentions of AS and so on, as we don't use the abbreviations in the spec.
*AI:* Domenico and Eve: D to create a beautiful flow chart according to the current draft spec for slideware purposes and E to create an ASCII version for spec purposes.
The current definition: "A correlation handle that represents a set of claims and interactions between the AS and the RqP/client pair during one authorization process to be used during future authorization processes. This MAY represent claims gathered interactively or pushed from the client. This MAY also represent any interactions the AS has with the RqP during this process, including any gathering of consent or authorization in any meaningful way. In short, this represents the sum total of the authorization process that a client went through to get its RPT (or even just trying to get its RPT). It’s intended to be used when this client gets a new RPT for this RqP at this AS, whether or not for the same resource or resource set and possibly for different policies or resource owners alltogether."
A potential way to change it: "A correlation handle that represents a set of claims and interactions between the authorization server and the requesting party/client pair during one authorization process to be used during future authorization processes. This represents a set of claims and/or interactions; the authorization server MAY have gathered the claims interactively or the client MAY have pushed them, and an end-user requesting party MAY have provided consent or authorization in some fashion to the authorization server for persisting this information across authorization processes."
Eve suggests moving the following text to Sec 1.3.2, where the conceptual explanation of the AAT used to be and where the conceptual explanation of the PCT kind of goes now: "The PCT represents the sum total of the authorization process that a client and its requesting part went through to obtain its RPT (or even just trying to get its RPT). It is intended to be used when this client obtain a new RPT for this requesting party at this authorization server, whether or not for the same resource set and possibly for different policies or resource owners."
Looking at the name of the UMA grant, why "uma-ticket"? Is it because we have a "ticket pattern"? Okay.
The PCT text in Sec 3.5.1 has us a bit confounded: "In circumstances where the authorization server returned an PCT previously when returning an RPT, the client MAY include the PCT. The PCT MAY have been obtained for a different resource at this AS, but since the PCT likely represents claims from the RqP it MUST be associated with the current RqP to the best of the client's abilities to determine this."
Let's unpack this. In the OAuth-based AAT solution, authentication would have been required, and the client would known for a certainty whether it was the same RqP. Now, it doesn't know for sure. Plus, if it's requesting access to a different resource, the policies and therefore trust elevation requirements could be different; hence, whatever package of claims and/or interactions might be different. The client can't know a priori. But the PCT is meant to be associated with "the same RqP" as far as the client is concerned, regardless of whatever trust elevation is required on the AS side, and regardless of whatever the AS requires, don't all clients pretty much require some kind of authentication for their own purposes? So couldn't any client do correlation of PCTs with their own users with 100% certainty?
*AI:* Eve: Get Justin's input on our analysis and questions.
In Sec 3.5.2, the first appearance of set math is hinted at: "The authorization server evaluates the policies in light of claims gathered from the client. These claims MAY be pushed directly by the client using the claim_tokens parameter, MAY be gathered interactively at the interactive claims gathering endpoint, and MAY be *represnted* by the persisted claims token (PCT) present by the client in the pct *paramter*. The authorization server MAY combine claims from these sources in any manner it chooses, though a simple union of all claims is reasonable."
(Note and fix typos.)
James had proposed set math as follows:
(ASDefaultClientScopes UNION ClientRequestScopes UNION PermissionTicketScopes) SUPER_SET_OR_EQUAL_TO PermissionTicketScopes
The questions for the spec are:
- What does the RS have to do at API publication time, if anything? - There *will* be scopes published, whether in informal fashion or, say, Swagger (machine-readable) - Nothing much more to say about this, probably (we have some editorial notes on it) - What does the client have to do at scope registration time, if anything? - It's never required for a client to register for scopes, but it could; this would limit what's possible for it to handle (we have some editorial notes on it) - *What does the RS have to do at permission ticket registration time?* - In UMA1, we've said it must register at least what the client attempted to access, but Justin has proposed letting it register any number of scopes, more/less/other - This remains to be fully discussed, though we started it at CIS - *Can the client request scopes from the RS (in addition to just attempting access)?* (added after the call: see George's comments from 2016-08-04 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-08-04> about efficiency of client communications for smart clients) - What does the client have to do at RPT request time? - *How does the client request scopes from the AS, and what can it ask for (e.g., what interaction does it have if it wants multiple resource sets)?* - In UMA1, the client couldn't ask for anything explicitly, but Justin's MPD exploration has made it possible (though not required) for the client to request scopes and we've agreed to make this possible - What does the AS have to do at RPT issuance time? - In UMA1, we've said the AS can issue a partial set of scopes if policy is only partially satisfied – are we still okay with that? We haven't discussed it - There are circumstances where only full matching will do (say, enterprise), and others where partial satisfaction would be good (consumer)
Spec instructions:
- See above!
Attendees
As of 31 Aug 2016, quorum is 6 of 10. (Domenico, Sal, Nagesh, Andi, Robert, Maciej, Eve, Jeffrey, Mike, Sarah)
1. Domenico 2. Sal 3. Nagesh 4. Robert 5. Eve
Non-voting participants:
- Andrew - Scott F - Kathleen - James
Regrets:
- Mike - John W - Andi
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
Okay, on that latter issue, working on the spec just now I think I may have broken the code, so to speak. The concern is that *the set of claims represented by the PCT may not be identical to what the client currently thinks it knows about the current RqP* -- right? Here's the brute-force formulation I'm trying in Sec 3.5.1... "If the authorization server previously returned a PCT along with an the RPT, the client MAY include the PCT in order to optimize the process of seeking a new RPT. Given that a PCT represents a set of requesting party claims, even if this PCT were obtained in the course of seeking access to a different resource or the same resource at a time when different resource owner policies applied, the client MUST make a best effort to ensure that it is associated with the same requesting party as previously." This helped me. Did I get it right? If so, did it help enough other people? Would it be worth adding "...a set of requesting party claims asked for by the authorization server"? (I think I can get to a couple more edits before publishing draft -03 sometime Monday.) *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Sun, Oct 2, 2016 at 10:18 PM, Eve Maler <eve@xmlgrrl.com> wrote:
Regarding claim combining, the more I think about it, I don't think we can really say too much. Claims (in band) are one thing and policy conditions (out of band) are another.
Any claims collected are, I think, just pieces of information in a flat space as far as UMA's "native claims data model" is concerned (so maybe we could go as far as saying that, while maybe pointing off to the extensibility section if you want to do more). On the other hand, policy expression models and engines could be arbitrarily sophisticated in what they do with that information: You have to be A, and not-B, and can optionally be C, and so on.
====
Regarding PCT care and feeding on the client side, I had been figuring that "persisted representation" of its user was at the heart of it, not leading language. I'm still not getting why the PCT having been issued on a visit to a different resource is so key. What if it were a visit to the same resource whose operative policies had changed or something? The *really* important thing is: What if the client goes back to the *identical* resource but the client is being wielded by a *different* RqP this time? What is the client's responsibility and how should it handle it?
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
On Fri, Sep 30, 2016 at 6:21 AM, Justin Richer <jricher@mit.edu> wrote:
On Sep 29, 2016, at 11:32 PM, Eve Maler <eve@xmlgrrl.com> wrote:
Regarding "math" of claims vs. scopes: Yes, of course, you're right, I think I got overexcited seeing we were getting near policy-matching. :-) In any case, I think we're close to getting back onto that topic.
Do we actually need to be saying "The authorization server MAY combine claims from these sources in any manner it chooses, though a simple union of all claims is reasonable."? On the one hand, what would happen if we said nothing (since the statement is non-testable)? On the other hand, what if someone wanted to create an extension trust elevation mechanism that added logical operators for claims gathering, indicating that some were optional and, if supplied, could be used at will or something?
Possibly needs to be more robust like that. I erred on the side of simplicity and based on my implementation: just smash all the things together. I think at the very least guidance to developers is a good idea otherwise we’re going to get mismatched expectations from clients presenting PCTs.
====
Regarding this text -- "The PCT MAY have been obtained for a different resource at this AS, but since the PCT likely represents claims from the RqP it MUST be associated with the current RqP to the best of the client's abilities to determine this." -- and the question of RqP matching:
So I think you're saying this was true before with AATs but we provided no guidance about it.
Correct.
And the reason you're mentioning different resources is because if it were the same resource, it would be more obviously the same RqP?
Possibly. Could be two RqPs using the same client to get the same resource, in which case it should be separate RPTs and separate PCTs. The same way an OAuth client getting a resource for two RO’s would get two access tokens and keep them separately tied to user sessions.
I feel like there's some leap being made there that I'm not quite grasping. Even if an attempt at access were being made to the "same resource" (a resource that had been accessed before by this client that had been handed a PCT and RPT, a PCT and RPT it is attempting to wield now), the client had better have done a good job of "RqP-matching" just as you're describing. I think.
Correct. What’s the leap? The requirement to match the PCT to the RqP is universal, but the PCT MAY have come from a different resource. Perhaps the sentence order should be swapped — were you reading the former part as a conditional? That’s not the intended interpretation.
Should we be saying something more like this? "If a client intends to use an issued PCT in a subsequent authorization process to represent the same requesting party, it MUST associate that PCT with its own persisted representation of that requesting party to the best of its ability.”
Something like that, avoiding “persisted representation” and other leading language of course.
— Justin
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
On Thu, Sep 29, 2016 at 2:43 PM, Justin Richer <jricher@mit.edu> wrote:
A note on this comment:
Let's unpack this. In the OAuth-based AAT solution, authentication would have been required, and the client would known for a certainty whether it was the same RqP. Now, it doesn't know for sure. Plus, if it's requesting access to a different resource, the policies and therefore trust elevation requirements could be different; hence, whatever package of claims and/or interactions might be different. The client can't know a priori. But the PCT is meant to be associated with "the same RqP" as far as the client is concerned, regardless of whatever trust elevation is required on the AS side, and regardless of whatever the AS requires, don't all clients pretty much require some kind of authentication for their own purposes? So couldn't any client do correlation of PCTs with their own users with 100% certainty?
The AAT doesn’t tell the client who the RqP is any more than any other OAuth access token does. The AAT represents an authenticated user at the AS, but not at the client. The PCT might represent authentication or any number of other things at the AS, but again not at the client. With an AAT, that means making sure you use the right AAT for the current RqP. With the PCT, the same condition applies: you only present the PCT associated with this RqP (and the claims the PCT represents). In both cases, it’s up to a multi-user client to manage its relationship with the RqP, and it’ll do so however it best sees fit. The client could do this binding to the “current RqP" on its side through authentication, or assuming it’s a single-user program (like a mobile app), or any number of other session management mechanisms. It’s not up to UMA to decide how it happens, but UMA does depend on it in exactly the same way that OAuth doesn’t say a word about how the client manages its connection to the RO, but depends on the client managing that connection.
So in the end, it’s exactly the same requirement and assumptions as before: before the client sends a token that ostensibly represents the RqP (either the AAT or PCT), it needs to be sure it’s sending the right token for the right RqP. The only difference here is that we’re explicitly spelling it out as a requirement instead of leaving it as implicit. I couldn’t find specific text in the OAuth RFCs dealing with this, but maybe someone else will have better luck searching.
Hope this clears things up on that point.
Also, note that the set math around the claims (from the PCT, pushed by client, and gathered interactively) is completely separate from and orthogonal to the set math around the scopes. Be careful not to conflate the two!
— Justin
On Sep 29, 2016, at 4:24 PM, Eve Maler <eve@xmlgrrl.com> wrote:
http://kantarainitiative.org/confluence/display/uma/UMA+tele con+2016-09-29 MinutesRoll call
Quorum was not reached. Approve minutes
Approve minutes of UMA telecon 2016-09-22 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-09-22> : Deferred. Work on UMA.next issues
We're wondering about the "authorization process" language in the new PCT definition. Instead of the three phases, we think a flowchart showing all of the AS responses to the client's request at the token endpoint (need_info and so on), and what the client has to do after that. E.g., if the client gets success and can then successfully access the resource, that's not "phase 3" but rather a successful singular termination of an "authorization process" and we should talk about it in that language. That's way more precise than just vaguely talking about "authorization process" without stating when such a thing starts and ends.
The definition also needs to expand mentions of AS and so on, as we don't use the abbreviations in the spec.
*AI:* Domenico and Eve: D to create a beautiful flow chart according to the current draft spec for slideware purposes and E to create an ASCII version for spec purposes.
The current definition: "A correlation handle that represents a set of claims and interactions between the AS and the RqP/client pair during one authorization process to be used during future authorization processes. This MAY represent claims gathered interactively or pushed from the client. This MAY also represent any interactions the AS has with the RqP during this process, including any gathering of consent or authorization in any meaningful way. In short, this represents the sum total of the authorization process that a client went through to get its RPT (or even just trying to get its RPT). It’s intended to be used when this client gets a new RPT for this RqP at this AS, whether or not for the same resource or resource set and possibly for different policies or resource owners alltogether."
A potential way to change it: "A correlation handle that represents a set of claims and interactions between the authorization server and the requesting party/client pair during one authorization process to be used during future authorization processes. This represents a set of claims and/or interactions; the authorization server MAY have gathered the claims interactively or the client MAY have pushed them, and an end-user requesting party MAY have provided consent or authorization in some fashion to the authorization server for persisting this information across authorization processes."
Eve suggests moving the following text to Sec 1.3.2, where the conceptual explanation of the AAT used to be and where the conceptual explanation of the PCT kind of goes now: "The PCT represents the sum total of the authorization process that a client and its requesting part went through to obtain its RPT (or even just trying to get its RPT). It is intended to be used when this client obtain a new RPT for this requesting party at this authorization server, whether or not for the same resource set and possibly for different policies or resource owners."
Looking at the name of the UMA grant, why "uma-ticket"? Is it because we have a "ticket pattern"? Okay.
The PCT text in Sec 3.5.1 has us a bit confounded: "In circumstances where the authorization server returned an PCT previously when returning an RPT, the client MAY include the PCT. The PCT MAY have been obtained for a different resource at this AS, but since the PCT likely represents claims from the RqP it MUST be associated with the current RqP to the best of the client's abilities to determine this."
Let's unpack this. In the OAuth-based AAT solution, authentication would have been required, and the client would known for a certainty whether it was the same RqP. Now, it doesn't know for sure. Plus, if it's requesting access to a different resource, the policies and therefore trust elevation requirements could be different; hence, whatever package of claims and/or interactions might be different. The client can't know a priori. But the PCT is meant to be associated with "the same RqP" as far as the client is concerned, regardless of whatever trust elevation is required on the AS side, and regardless of whatever the AS requires, don't all clients pretty much require some kind of authentication for their own purposes? So couldn't any client do correlation of PCTs with their own users with 100% certainty?
*AI:* Eve: Get Justin's input on our analysis and questions.
In Sec 3.5.2, the first appearance of set math is hinted at: "The authorization server evaluates the policies in light of claims gathered from the client. These claims MAY be pushed directly by the client using the claim_tokens parameter, MAY be gathered interactively at the interactive claims gathering endpoint, and MAY be *represnted* by the persisted claims token (PCT) present by the client in the pct *paramter*. The authorization server MAY combine claims from these sources in any manner it chooses, though a simple union of all claims is reasonable."
(Note and fix typos.)
James had proposed set math as follows:
(ASDefaultClientScopes UNION ClientRequestScopes UNION PermissionTicketScopes) SUPER_SET_OR_EQUAL_TO PermissionTicketScopes
The questions for the spec are:
- What does the RS have to do at API publication time, if anything? - There *will* be scopes published, whether in informal fashion or, say, Swagger (machine-readable) - Nothing much more to say about this, probably (we have some editorial notes on it) - What does the client have to do at scope registration time, if anything? - It's never required for a client to register for scopes, but it could; this would limit what's possible for it to handle (we have some editorial notes on it) - *What does the RS have to do at permission ticket registration time?* - In UMA1, we've said it must register at least what the client attempted to access, but Justin has proposed letting it register any number of scopes, more/less/other - This remains to be fully discussed, though we started it at CIS - *Can the client request scopes from the RS (in addition to just attempting access)?* (added after the call: see George's comments from 2016-08-04 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-08-04> about efficiency of client communications for smart clients) - What does the client have to do at RPT request time? - *How does the client request scopes from the AS, and what can it ask for (e.g., what interaction does it have if it wants multiple resource sets)?* - In UMA1, the client couldn't ask for anything explicitly, but Justin's MPD exploration has made it possible (though not required) for the client to request scopes and we've agreed to make this possible - What does the AS have to do at RPT issuance time? - In UMA1, we've said the AS can issue a partial set of scopes if policy is only partially satisfied – are we still okay with that? We haven't discussed it - There are circumstances where only full matching will do (say, enterprise), and others where partial satisfaction would be good (consumer)
Spec instructions:
- See above!
Attendees
As of 31 Aug 2016, quorum is 6 of 10. (Domenico, Sal, Nagesh, Andi, Robert, Maciej, Eve, Jeffrey, Mike, Sarah)
1. Domenico 2. Sal 3. Nagesh 4. Robert 5. Eve
Non-voting participants:
- Andrew - Scott F - Kathleen - James
Regrets:
- Mike - John W - Andi
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
The point is that it doesn’t matter whether the client is accessing the same resource or not. That part is immaterial, and I think my inclusion of the text in the definition was misleading. The intended meaning of the text doesn’t change when you pull that part out entirely: If the authorization server previously returned a PCT along with an RPT, the client MAY include the PCT in order to optimize the process of seeking a new RPT. Given that a PCT represents a set of requesting party claims, the client MUST make a best effort to ensure that it is associated with the same requesting party as previously. Does this make it clearer? Just wanted to point out that it isn’t tied to the resource. — Justin
On Oct 3, 2016, at 1:45 AM, Eve Maler <eve@xmlgrrl.com> wrote:
Okay, on that latter issue, working on the spec just now I think I may have broken the code, so to speak. The concern is that the set of claims represented by the PCT may not be identical to what the client currently thinks it knows about the current RqP -- right?
Here's the brute-force formulation I'm trying in Sec 3.5.1...
"If the authorization server previously returned a PCT along with an the RPT, the client MAY include the PCT in order to optimize the process of seeking a new RPT. Given that a PCT represents a set of requesting party claims, even if this PCT were obtained in the course of seeking access to a different resource or the same resource at a time when different resource owner policies applied, the client MUST make a best effort to ensure that it is associated with the same requesting party as previously."
This helped me. Did I get it right? If so, did it help enough other people? Would it be worth adding "...a set of requesting party claims asked for by the authorization server"?
(I think I can get to a couple more edits before publishing draft -03 sometime Monday.)
Eve Maler Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
On Sun, Oct 2, 2016 at 10:18 PM, Eve Maler <eve@xmlgrrl.com <mailto:eve@xmlgrrl.com>> wrote: Regarding claim combining, the more I think about it, I don't think we can really say too much. Claims (in band) are one thing and policy conditions (out of band) are another.
Any claims collected are, I think, just pieces of information in a flat space as far as UMA's "native claims data model" is concerned (so maybe we could go as far as saying that, while maybe pointing off to the extensibility section if you want to do more). On the other hand, policy expression models and engines could be arbitrarily sophisticated in what they do with that information: You have to be A, and not-B, and can optionally be C, and so on.
====
Regarding PCT care and feeding on the client side, I had been figuring that "persisted representation" of its user was at the heart of it, not leading language. I'm still not getting why the PCT having been issued on a visit to a different resource is so key. What if it were a visit to the same resource whose operative policies had changed or something? The really important thing is: What if the client goes back to the identical resource but the client is being wielded by a different RqP this time? What is the client's responsibility and how should it handle it?
Eve Maler Cell +1 425.345.6756 <tel:%2B1%20425.345.6756> | Skype: xmlgrrl | Twitter: @xmlgrrl
On Fri, Sep 30, 2016 at 6:21 AM, Justin Richer <jricher@mit.edu <mailto:jricher@mit.edu>> wrote:
On Sep 29, 2016, at 11:32 PM, Eve Maler <eve@xmlgrrl.com <mailto:eve@xmlgrrl.com>> wrote:
Regarding "math" of claims vs. scopes: Yes, of course, you're right, I think I got overexcited seeing we were getting near policy-matching. :-) In any case, I think we're close to getting back onto that topic.
Do we actually need to be saying "The authorization server MAY combine claims from these sources in any manner it chooses, though a simple union of all claims is reasonable."? On the one hand, what would happen if we said nothing (since the statement is non-testable)? On the other hand, what if someone wanted to create an extension trust elevation mechanism that added logical operators for claims gathering, indicating that some were optional and, if supplied, could be used at will or something?
Possibly needs to be more robust like that. I erred on the side of simplicity and based on my implementation: just smash all the things together. I think at the very least guidance to developers is a good idea otherwise we’re going to get mismatched expectations from clients presenting PCTs.
====
Regarding this text -- "The PCT MAY have been obtained for a different resource at this AS, but since the PCT likely represents claims from the RqP it MUST be associated with the current RqP to the best of the client's abilities to determine this." -- and the question of RqP matching:
So I think you're saying this was true before with AATs but we provided no guidance about it.
Correct.
And the reason you're mentioning different resources is because if it were the same resource, it would be more obviously the same RqP?
Possibly. Could be two RqPs using the same client to get the same resource, in which case it should be separate RPTs and separate PCTs. The same way an OAuth client getting a resource for two RO’s would get two access tokens and keep them separately tied to user sessions.
I feel like there's some leap being made there that I'm not quite grasping. Even if an attempt at access were being made to the "same resource" (a resource that had been accessed before by this client that had been handed a PCT and RPT, a PCT and RPT it is attempting to wield now), the client had better have done a good job of "RqP-matching" just as you're describing. I think.
Correct. What’s the leap? The requirement to match the PCT to the RqP is universal, but the PCT MAY have come from a different resource. Perhaps the sentence order should be swapped — were you reading the former part as a conditional? That’s not the intended interpretation.
Should we be saying something more like this? "If a client intends to use an issued PCT in a subsequent authorization process to represent the same requesting party, it MUST associate that PCT with its own persisted representation of that requesting party to the best of its ability.”
Something like that, avoiding “persisted representation” and other leading language of course.
— Justin
Eve Maler Cell +1 425.345.6756 <tel:%2B1%20425.345.6756> | Skype: xmlgrrl | Twitter: @xmlgrrl
On Thu, Sep 29, 2016 at 2:43 PM, Justin Richer <jricher@mit.edu <mailto:jricher@mit.edu>> wrote: A note on this comment:
Let's unpack this. In the OAuth-based AAT solution, authentication would have been required, and the client would known for a certainty whether it was the same RqP. Now, it doesn't know for sure. Plus, if it's requesting access to a different resource, the policies and therefore trust elevation requirements could be different; hence, whatever package of claims and/or interactions might be different. The client can't know a priori. But the PCT is meant to be associated with "the same RqP" as far as the client is concerned, regardless of whatever trust elevation is required on the AS side, and regardless of whatever the AS requires, don't all clients pretty much require some kind of authentication for their own purposes? So couldn't any client do correlation of PCTs with their own users with 100% certainty?
The AAT doesn’t tell the client who the RqP is any more than any other OAuth access token does. The AAT represents an authenticated user at the AS, but not at the client. The PCT might represent authentication or any number of other things at the AS, but again not at the client. With an AAT, that means making sure you use the right AAT for the current RqP. With the PCT, the same condition applies: you only present the PCT associated with this RqP (and the claims the PCT represents). In both cases, it’s up to a multi-user client to manage its relationship with the RqP, and it’ll do so however it best sees fit. The client could do this binding to the “current RqP" on its side through authentication, or assuming it’s a single-user program (like a mobile app), or any number of other session management mechanisms. It’s not up to UMA to decide how it happens, but UMA does depend on it in exactly the same way that OAuth doesn’t say a word about how the client manages its connection to the RO, but depends on the client managing that connection.
So in the end, it’s exactly the same requirement and assumptions as before: before the client sends a token that ostensibly represents the RqP (either the AAT or PCT), it needs to be sure it’s sending the right token for the right RqP. The only difference here is that we’re explicitly spelling it out as a requirement instead of leaving it as implicit. I couldn’t find specific text in the OAuth RFCs dealing with this, but maybe someone else will have better luck searching.
Hope this clears things up on that point.
Also, note that the set math around the claims (from the PCT, pushed by client, and gathered interactively) is completely separate from and orthogonal to the set math around the scopes. Be careful not to conflate the two!
— Justin
On Sep 29, 2016, at 4:24 PM, Eve Maler <eve@xmlgrrl.com <mailto:eve@xmlgrrl.com>> wrote:
http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-09-29 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-09-29> Minutes Roll call Quorum was not reached. Approve minutes Approve minutes of UMA telecon 2016-09-22 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-09-22> : Deferred. Work on UMA.next issues We're wondering about the "authorization process" language in the new PCT definition. Instead of the three phases, we think a flowchart showing all of the AS responses to the client's request at the token endpoint (need_info and so on), and what the client has to do after that. E.g., if the client gets success and can then successfully access the resource, that's not "phase 3" but rather a successful singular termination of an "authorization process" and we should talk about it in that language. That's way more precise than just vaguely talking about "authorization process" without stating when such a thing starts and ends. The definition also needs to expand mentions of AS and so on, as we don't use the abbreviations in the spec. AI: Domenico and Eve: D to create a beautiful flow chart according to the current draft spec for slideware purposes and E to create an ASCII version for spec purposes. The current definition: "A correlation handle that represents a set of claims and interactions between the AS and the RqP/client pair during one authorization process to be used during future authorization processes. This MAY represent claims gathered interactively or pushed from the client. This MAY also represent any interactions the AS has with the RqP during this process, including any gathering of consent or authorization in any meaningful way. In short, this represents the sum total of the authorization process that a client went through to get its RPT (or even just trying to get its RPT). It’s intended to be used when this client gets a new RPT for this RqP at this AS, whether or not for the same resource or resource set and possibly for different policies or resource owners alltogether." A potential way to change it: "A correlation handle that represents a set of claims and interactions between the authorization server and the requesting party/client pair during one authorization process to be used during future authorization processes. This represents a set of claims and/or interactions; the authorization server MAY have gathered the claims interactively or the client MAY have pushed them, and an end-user requesting party MAY have provided consent or authorization in some fashion to the authorization server for persisting this information across authorization processes." Eve suggests moving the following text to Sec 1.3.2, where the conceptual explanation of the AAT used to be and where the conceptual explanation of the PCT kind of goes now: "The PCT represents the sum total of the authorization process that a client and its requesting part went through to obtain its RPT (or even just trying to get its RPT). It is intended to be used when this client obtain a new RPT for this requesting party at this authorization server, whether or not for the same resource set and possibly for different policies or resource owners." Looking at the name of the UMA grant, why "uma-ticket"? Is it because we have a "ticket pattern"? Okay. The PCT text in Sec 3.5.1 has us a bit confounded: "In circumstances where the authorization server returned an PCT previously when returning an RPT, the client MAY include the PCT. The PCT MAY have been obtained for a different resource at this AS, but since the PCT likely represents claims from the RqP it MUST be associated with the current RqP to the best of the client's abilities to determine this." Let's unpack this. In the OAuth-based AAT solution, authentication would have been required, and the client would known for a certainty whether it was the same RqP. Now, it doesn't know for sure. Plus, if it's requesting access to a different resource, the policies and therefore trust elevation requirements could be different; hence, whatever package of claims and/or interactions might be different. The client can't know a priori. But the PCT is meant to be associated with "the same RqP" as far as the client is concerned, regardless of whatever trust elevation is required on the AS side, and regardless of whatever the AS requires, don't all clients pretty much require some kind of authentication for their own purposes? So couldn't any client do correlation of PCTs with their own users with 100% certainty? AI: Eve: Get Justin's input on our analysis and questions. In Sec 3.5.2, the first appearance of set math is hinted at: "The authorization server evaluates the policies in light of claims gathered from the client. These claims MAY be pushed directly by the client using the claim_tokens parameter, MAY be gathered interactively at the interactive claims gathering endpoint, and MAY be represnted by the persisted claims token (PCT) present by the client in the pct paramter. The authorization server MAY combine claims from these sources in any manner it chooses, though a simple union of all claims is reasonable." (Note and fix typos.) James had proposed set math as follows: (ASDefaultClientScopes UNION ClientRequestScopes UNION PermissionTicketScopes) SUPER_SET_OR_EQUAL_TO PermissionTicketScopes The questions for the spec are: What does the RS have to do at API publication time, if anything? There will be scopes published, whether in informal fashion or, say, Swagger (machine-readable) Nothing much more to say about this, probably (we have some editorial notes on it) What does the client have to do at scope registration time, if anything? It's never required for a client to register for scopes, but it could; this would limit what's possible for it to handle (we have some editorial notes on it) What does the RS have to do at permission ticket registration time? In UMA1, we've said it must register at least what the client attempted to access, but Justin has proposed letting it register any number of scopes, more/less/other This remains to be fully discussed, though we started it at CIS Can the client request scopes from the RS (in addition to just attempting access)? (added after the call: see George's comments from 2016-08-04 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-08-04> about efficiency of client communications for smart clients) What does the client have to do at RPT request time? How does the client request scopes from the AS, and what can it ask for (e.g., what interaction does it have if it wants multiple resource sets)? In UMA1, the client couldn't ask for anything explicitly, but Justin's MPD exploration has made it possible (though not required) for the client to request scopes and we've agreed to make this possible What does the AS have to do at RPT issuance time? In UMA1, we've said the AS can issue a partial set of scopes if policy is only partially satisfied – are we still okay with that? We haven't discussed it There are circumstances where only full matching will do (say, enterprise), and others where partial satisfaction would be good (consumer) Spec instructions: See above! Attendees As of 31 Aug 2016, quorum is 6 of 10. (Domenico, Sal, Nagesh, Andi, Robert, Maciej, Eve, Jeffrey, Mike, Sarah) Domenico Sal Nagesh Robert Eve Non-voting participants: Andrew Scott F Kathleen James Regrets: Mike John W Andi
Eve Maler Cell +1 425.345.6756 <tel:%2B1%20425.345.6756> | Skype: xmlgrrl | Twitter: @xmlgrrl
_______________________________________________ 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>
Oh, and to answer the embedded question:
What if the client goes back to the identical resource but the client is being wielded by a different RqP this time? What is the client's responsibility and how should it handle it?
In my view, the client MUST NOT present a PCT that was gathered while the client was being wielded by a different RqP. The claims represented by the PCT no longer represent the current user of the client. — Justin
On Oct 3, 2016, at 2:41 PM, Justin Richer <jricher@MIT.EDU> wrote:
The point is that it doesn’t matter whether the client is accessing the same resource or not. That part is immaterial, and I think my inclusion of the text in the definition was misleading. The intended meaning of the text doesn’t change when you pull that part out entirely:
If the authorization server previously returned a PCT along with an RPT, the client MAY include the PCT in order to optimize the process of seeking a new RPT. Given that a PCT represents a set of requesting party claims, the client MUST make a best effort to ensure that it is associated with the same requesting party as previously.
Does this make it clearer? Just wanted to point out that it isn’t tied to the resource.
— Justin
On Oct 3, 2016, at 1:45 AM, Eve Maler <eve@xmlgrrl.com <mailto:eve@xmlgrrl.com>> wrote:
Okay, on that latter issue, working on the spec just now I think I may have broken the code, so to speak. The concern is that the set of claims represented by the PCT may not be identical to what the client currently thinks it knows about the current RqP -- right?
Here's the brute-force formulation I'm trying in Sec 3.5.1...
"If the authorization server previously returned a PCT along with an the RPT, the client MAY include the PCT in order to optimize the process of seeking a new RPT. Given that a PCT represents a set of requesting party claims, even if this PCT were obtained in the course of seeking access to a different resource or the same resource at a time when different resource owner policies applied, the client MUST make a best effort to ensure that it is associated with the same requesting party as previously."
This helped me. Did I get it right? If so, did it help enough other people? Would it be worth adding "...a set of requesting party claims asked for by the authorization server"?
(I think I can get to a couple more edits before publishing draft -03 sometime Monday.)
Eve Maler Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
On Sun, Oct 2, 2016 at 10:18 PM, Eve Maler <eve@xmlgrrl.com <mailto:eve@xmlgrrl.com>> wrote: Regarding claim combining, the more I think about it, I don't think we can really say too much. Claims (in band) are one thing and policy conditions (out of band) are another.
Any claims collected are, I think, just pieces of information in a flat space as far as UMA's "native claims data model" is concerned (so maybe we could go as far as saying that, while maybe pointing off to the extensibility section if you want to do more). On the other hand, policy expression models and engines could be arbitrarily sophisticated in what they do with that information: You have to be A, and not-B, and can optionally be C, and so on.
====
Regarding PCT care and feeding on the client side, I had been figuring that "persisted representation" of its user was at the heart of it, not leading language. I'm still not getting why the PCT having been issued on a visit to a different resource is so key. What if it were a visit to the same resource whose operative policies had changed or something? The really important thing is: What if the client goes back to the identical resource but the client is being wielded by a different RqP this time? What is the client's responsibility and how should it handle it?
Eve Maler Cell +1 425.345.6756 <tel:%2B1%20425.345.6756> | Skype: xmlgrrl | Twitter: @xmlgrrl
On Fri, Sep 30, 2016 at 6:21 AM, Justin Richer <jricher@mit.edu <mailto:jricher@mit.edu>> wrote:
On Sep 29, 2016, at 11:32 PM, Eve Maler <eve@xmlgrrl.com <mailto:eve@xmlgrrl.com>> wrote:
Regarding "math" of claims vs. scopes: Yes, of course, you're right, I think I got overexcited seeing we were getting near policy-matching. :-) In any case, I think we're close to getting back onto that topic.
Do we actually need to be saying "The authorization server MAY combine claims from these sources in any manner it chooses, though a simple union of all claims is reasonable."? On the one hand, what would happen if we said nothing (since the statement is non-testable)? On the other hand, what if someone wanted to create an extension trust elevation mechanism that added logical operators for claims gathering, indicating that some were optional and, if supplied, could be used at will or something?
Possibly needs to be more robust like that. I erred on the side of simplicity and based on my implementation: just smash all the things together. I think at the very least guidance to developers is a good idea otherwise we’re going to get mismatched expectations from clients presenting PCTs.
====
Regarding this text -- "The PCT MAY have been obtained for a different resource at this AS, but since the PCT likely represents claims from the RqP it MUST be associated with the current RqP to the best of the client's abilities to determine this." -- and the question of RqP matching:
So I think you're saying this was true before with AATs but we provided no guidance about it.
Correct.
And the reason you're mentioning different resources is because if it were the same resource, it would be more obviously the same RqP?
Possibly. Could be two RqPs using the same client to get the same resource, in which case it should be separate RPTs and separate PCTs. The same way an OAuth client getting a resource for two RO’s would get two access tokens and keep them separately tied to user sessions.
I feel like there's some leap being made there that I'm not quite grasping. Even if an attempt at access were being made to the "same resource" (a resource that had been accessed before by this client that had been handed a PCT and RPT, a PCT and RPT it is attempting to wield now), the client had better have done a good job of "RqP-matching" just as you're describing. I think.
Correct. What’s the leap? The requirement to match the PCT to the RqP is universal, but the PCT MAY have come from a different resource. Perhaps the sentence order should be swapped — were you reading the former part as a conditional? That’s not the intended interpretation.
Should we be saying something more like this? "If a client intends to use an issued PCT in a subsequent authorization process to represent the same requesting party, it MUST associate that PCT with its own persisted representation of that requesting party to the best of its ability.”
Something like that, avoiding “persisted representation” and other leading language of course.
— Justin
Eve Maler Cell +1 425.345.6756 <tel:%2B1%20425.345.6756> | Skype: xmlgrrl | Twitter: @xmlgrrl
On Thu, Sep 29, 2016 at 2:43 PM, Justin Richer <jricher@mit.edu <mailto:jricher@mit.edu>> wrote: A note on this comment:
Let's unpack this. In the OAuth-based AAT solution, authentication would have been required, and the client would known for a certainty whether it was the same RqP. Now, it doesn't know for sure. Plus, if it's requesting access to a different resource, the policies and therefore trust elevation requirements could be different; hence, whatever package of claims and/or interactions might be different. The client can't know a priori. But the PCT is meant to be associated with "the same RqP" as far as the client is concerned, regardless of whatever trust elevation is required on the AS side, and regardless of whatever the AS requires, don't all clients pretty much require some kind of authentication for their own purposes? So couldn't any client do correlation of PCTs with their own users with 100% certainty?
The AAT doesn’t tell the client who the RqP is any more than any other OAuth access token does. The AAT represents an authenticated user at the AS, but not at the client. The PCT might represent authentication or any number of other things at the AS, but again not at the client. With an AAT, that means making sure you use the right AAT for the current RqP. With the PCT, the same condition applies: you only present the PCT associated with this RqP (and the claims the PCT represents). In both cases, it’s up to a multi-user client to manage its relationship with the RqP, and it’ll do so however it best sees fit. The client could do this binding to the “current RqP" on its side through authentication, or assuming it’s a single-user program (like a mobile app), or any number of other session management mechanisms. It’s not up to UMA to decide how it happens, but UMA does depend on it in exactly the same way that OAuth doesn’t say a word about how the client manages its connection to the RO, but depends on the client managing that connection.
So in the end, it’s exactly the same requirement and assumptions as before: before the client sends a token that ostensibly represents the RqP (either the AAT or PCT), it needs to be sure it’s sending the right token for the right RqP. The only difference here is that we’re explicitly spelling it out as a requirement instead of leaving it as implicit. I couldn’t find specific text in the OAuth RFCs dealing with this, but maybe someone else will have better luck searching.
Hope this clears things up on that point.
Also, note that the set math around the claims (from the PCT, pushed by client, and gathered interactively) is completely separate from and orthogonal to the set math around the scopes. Be careful not to conflate the two!
— Justin
On Sep 29, 2016, at 4:24 PM, Eve Maler <eve@xmlgrrl.com <mailto:eve@xmlgrrl.com>> wrote:
http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-09-29 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-09-29> Minutes Roll call Quorum was not reached. Approve minutes Approve minutes of UMA telecon 2016-09-22 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-09-22> : Deferred. Work on UMA.next issues We're wondering about the "authorization process" language in the new PCT definition. Instead of the three phases, we think a flowchart showing all of the AS responses to the client's request at the token endpoint (need_info and so on), and what the client has to do after that. E.g., if the client gets success and can then successfully access the resource, that's not "phase 3" but rather a successful singular termination of an "authorization process" and we should talk about it in that language. That's way more precise than just vaguely talking about "authorization process" without stating when such a thing starts and ends. The definition also needs to expand mentions of AS and so on, as we don't use the abbreviations in the spec. AI: Domenico and Eve: D to create a beautiful flow chart according to the current draft spec for slideware purposes and E to create an ASCII version for spec purposes. The current definition: "A correlation handle that represents a set of claims and interactions between the AS and the RqP/client pair during one authorization process to be used during future authorization processes. This MAY represent claims gathered interactively or pushed from the client. This MAY also represent any interactions the AS has with the RqP during this process, including any gathering of consent or authorization in any meaningful way. In short, this represents the sum total of the authorization process that a client went through to get its RPT (or even just trying to get its RPT). It’s intended to be used when this client gets a new RPT for this RqP at this AS, whether or not for the same resource or resource set and possibly for different policies or resource owners alltogether." A potential way to change it: "A correlation handle that represents a set of claims and interactions between the authorization server and the requesting party/client pair during one authorization process to be used during future authorization processes. This represents a set of claims and/or interactions; the authorization server MAY have gathered the claims interactively or the client MAY have pushed them, and an end-user requesting party MAY have provided consent or authorization in some fashion to the authorization server for persisting this information across authorization processes." Eve suggests moving the following text to Sec 1.3.2, where the conceptual explanation of the AAT used to be and where the conceptual explanation of the PCT kind of goes now: "The PCT represents the sum total of the authorization process that a client and its requesting part went through to obtain its RPT (or even just trying to get its RPT). It is intended to be used when this client obtain a new RPT for this requesting party at this authorization server, whether or not for the same resource set and possibly for different policies or resource owners." Looking at the name of the UMA grant, why "uma-ticket"? Is it because we have a "ticket pattern"? Okay. The PCT text in Sec 3.5.1 has us a bit confounded: "In circumstances where the authorization server returned an PCT previously when returning an RPT, the client MAY include the PCT. The PCT MAY have been obtained for a different resource at this AS, but since the PCT likely represents claims from the RqP it MUST be associated with the current RqP to the best of the client's abilities to determine this." Let's unpack this. In the OAuth-based AAT solution, authentication would have been required, and the client would known for a certainty whether it was the same RqP. Now, it doesn't know for sure. Plus, if it's requesting access to a different resource, the policies and therefore trust elevation requirements could be different; hence, whatever package of claims and/or interactions might be different. The client can't know a priori. But the PCT is meant to be associated with "the same RqP" as far as the client is concerned, regardless of whatever trust elevation is required on the AS side, and regardless of whatever the AS requires, don't all clients pretty much require some kind of authentication for their own purposes? So couldn't any client do correlation of PCTs with their own users with 100% certainty? AI: Eve: Get Justin's input on our analysis and questions. In Sec 3.5.2, the first appearance of set math is hinted at: "The authorization server evaluates the policies in light of claims gathered from the client. These claims MAY be pushed directly by the client using the claim_tokens parameter, MAY be gathered interactively at the interactive claims gathering endpoint, and MAY be represnted by the persisted claims token (PCT) present by the client in the pct paramter. The authorization server MAY combine claims from these sources in any manner it chooses, though a simple union of all claims is reasonable." (Note and fix typos.) James had proposed set math as follows: (ASDefaultClientScopes UNION ClientRequestScopes UNION PermissionTicketScopes) SUPER_SET_OR_EQUAL_TO PermissionTicketScopes The questions for the spec are: What does the RS have to do at API publication time, if anything? There will be scopes published, whether in informal fashion or, say, Swagger (machine-readable) Nothing much more to say about this, probably (we have some editorial notes on it) What does the client have to do at scope registration time, if anything? It's never required for a client to register for scopes, but it could; this would limit what's possible for it to handle (we have some editorial notes on it) What does the RS have to do at permission ticket registration time? In UMA1, we've said it must register at least what the client attempted to access, but Justin has proposed letting it register any number of scopes, more/less/other This remains to be fully discussed, though we started it at CIS Can the client request scopes from the RS (in addition to just attempting access)? (added after the call: see George's comments from 2016-08-04 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-08-04> about efficiency of client communications for smart clients) What does the client have to do at RPT request time? How does the client request scopes from the AS, and what can it ask for (e.g., what interaction does it have if it wants multiple resource sets)? In UMA1, the client couldn't ask for anything explicitly, but Justin's MPD exploration has made it possible (though not required) for the client to request scopes and we've agreed to make this possible What does the AS have to do at RPT issuance time? In UMA1, we've said the AS can issue a partial set of scopes if policy is only partially satisfied – are we still okay with that? We haven't discussed it There are circumstances where only full matching will do (say, enterprise), and others where partial satisfaction would be good (consumer) Spec instructions: See above! Attendees As of 31 Aug 2016, quorum is 6 of 10. (Domenico, Sal, Nagesh, Andi, Robert, Maciej, Eve, Jeffrey, Mike, Sarah) Domenico Sal Nagesh Robert Eve Non-voting participants: Andrew Scott F Kathleen James Regrets: Mike John W Andi
Eve Maler Cell +1 425.345.6756 <tel:%2B1%20425.345.6756> | Skype: xmlgrrl | Twitter: @xmlgrrl
_______________________________________________ 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
Justin - does that mean that the client shouldn't use a 'best effort' to ensure that they have the same RqP present. They must be positive that it is the same RqP. One possible mechanism might be to match a client-side authentication of the RqP to some identifier in the PCT? Because the PCT is a set of claims about the RqP, not a set of 'authorization decision results' at the AS. The AS might have to evaluate authorization policy again using the AS-stored claims referenced by the PCT. andrew. *Andrew Hughes *CISM CISSP Independent Consultant *In Turn Information Management Consulting* o +1 650.209.7542 m +1 250.888.9474 1249 Palmer Road, Victoria, BC V8P 2H8 AndrewHughes3000@gmail.com ca.linkedin.com/pub/andrew-hughes/a/58/682/ *Identity Management | IT Governance | Information Security * On Mon, Oct 3, 2016 at 11:47 AM, Justin Richer <jricher@mit.edu> wrote:
Oh, and to answer the embedded question:
What if the client goes back to the *identical* resource but the client
is being wielded by a *different* RqP this time? What is the client's responsibility and how should it handle it?
In my view, the client MUST NOT present a PCT that was gathered while the client was being wielded by a different RqP. The claims represented by the PCT no longer represent the current user of the client.
— Justin
On Oct 3, 2016, at 2:41 PM, Justin Richer <jricher@MIT.EDU <jricher@mit.edu>> wrote:
The point is that it doesn’t matter whether the client is accessing the same resource or not. That part is immaterial, and I think my inclusion of the text in the definition was misleading. The intended meaning of the text doesn’t change when you pull that part out entirely:
If the authorization server previously returned a PCT along with an RPT, the client MAY include the PCT in order to optimize the process of seeking a new RPT. Given that a PCT represents a set of requesting party claims, the client MUST make a best effort to ensure that it is associated with the same requesting party as previously.
Does this make it clearer? Just wanted to point out that it isn’t tied to the resource.
— Justin
On Oct 3, 2016, at 1:45 AM, Eve Maler <eve@xmlgrrl.com> wrote:
Okay, on that latter issue, working on the spec just now I think I may have broken the code, so to speak. The concern is that *the set of claims represented by the PCT may not be identical to what the client currently thinks it knows about the current RqP* -- right?
Here's the brute-force formulation I'm trying in Sec 3.5.1...
"If the authorization server previously returned a PCT along with an the RPT, the client MAY include the PCT in order to optimize the process of seeking a new RPT. Given that a PCT represents a set of requesting party claims, even if this PCT were obtained in the course of seeking access to a different resource or the same resource at a time when different resource owner policies applied, the client MUST make a best effort to ensure that it is associated with the same requesting party as previously."
This helped me. Did I get it right? If so, did it help enough other people? Would it be worth adding "...a set of requesting party claims asked for by the authorization server"?
(I think I can get to a couple more edits before publishing draft -03 sometime Monday.)
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
On Sun, Oct 2, 2016 at 10:18 PM, Eve Maler <eve@xmlgrrl.com> wrote:
Regarding claim combining, the more I think about it, I don't think we can really say too much. Claims (in band) are one thing and policy conditions (out of band) are another.
Any claims collected are, I think, just pieces of information in a flat space as far as UMA's "native claims data model" is concerned (so maybe we could go as far as saying that, while maybe pointing off to the extensibility section if you want to do more). On the other hand, policy expression models and engines could be arbitrarily sophisticated in what they do with that information: You have to be A, and not-B, and can optionally be C, and so on.
====
Regarding PCT care and feeding on the client side, I had been figuring that "persisted representation" of its user was at the heart of it, not leading language. I'm still not getting why the PCT having been issued on a visit to a different resource is so key. What if it were a visit to the same resource whose operative policies had changed or something? The *really* important thing is: What if the client goes back to the *identical* resource but the client is being wielded by a *different* RqP this time? What is the client's responsibility and how should it handle it?
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
On Fri, Sep 30, 2016 at 6:21 AM, Justin Richer <jricher@mit.edu> wrote:
On Sep 29, 2016, at 11:32 PM, Eve Maler <eve@xmlgrrl.com> wrote:
Regarding "math" of claims vs. scopes: Yes, of course, you're right, I think I got overexcited seeing we were getting near policy-matching. :-) In any case, I think we're close to getting back onto that topic.
Do we actually need to be saying "The authorization server MAY combine claims from these sources in any manner it chooses, though a simple union of all claims is reasonable."? On the one hand, what would happen if we said nothing (since the statement is non-testable)? On the other hand, what if someone wanted to create an extension trust elevation mechanism that added logical operators for claims gathering, indicating that some were optional and, if supplied, could be used at will or something?
Possibly needs to be more robust like that. I erred on the side of simplicity and based on my implementation: just smash all the things together. I think at the very least guidance to developers is a good idea otherwise we’re going to get mismatched expectations from clients presenting PCTs.
====
Regarding this text -- "The PCT MAY have been obtained for a different resource at this AS, but since the PCT likely represents claims from the RqP it MUST be associated with the current RqP to the best of the client's abilities to determine this." -- and the question of RqP matching:
So I think you're saying this was true before with AATs but we provided no guidance about it.
Correct.
And the reason you're mentioning different resources is because if it were the same resource, it would be more obviously the same RqP?
Possibly. Could be two RqPs using the same client to get the same resource, in which case it should be separate RPTs and separate PCTs. The same way an OAuth client getting a resource for two RO’s would get two access tokens and keep them separately tied to user sessions.
I feel like there's some leap being made there that I'm not quite grasping. Even if an attempt at access were being made to the "same resource" (a resource that had been accessed before by this client that had been handed a PCT and RPT, a PCT and RPT it is attempting to wield now), the client had better have done a good job of "RqP-matching" just as you're describing. I think.
Correct. What’s the leap? The requirement to match the PCT to the RqP is universal, but the PCT MAY have come from a different resource. Perhaps the sentence order should be swapped — were you reading the former part as a conditional? That’s not the intended interpretation.
Should we be saying something more like this? "If a client intends to use an issued PCT in a subsequent authorization process to represent the same requesting party, it MUST associate that PCT with its own persisted representation of that requesting party to the best of its ability.”
Something like that, avoiding “persisted representation” and other leading language of course.
— Justin
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
On Thu, Sep 29, 2016 at 2:43 PM, Justin Richer <jricher@mit.edu> wrote:
A note on this comment:
Let's unpack this. In the OAuth-based AAT solution, authentication would have been required, and the client would known for a certainty whether it was the same RqP. Now, it doesn't know for sure. Plus, if it's requesting access to a different resource, the policies and therefore trust elevation requirements could be different; hence, whatever package of claims and/or interactions might be different. The client can't know a priori. But the PCT is meant to be associated with "the same RqP" as far as the client is concerned, regardless of whatever trust elevation is required on the AS side, and regardless of whatever the AS requires, don't all clients pretty much require some kind of authentication for their own purposes? So couldn't any client do correlation of PCTs with their own users with 100% certainty?
The AAT doesn’t tell the client who the RqP is any more than any other OAuth access token does. The AAT represents an authenticated user at the AS, but not at the client. The PCT might represent authentication or any number of other things at the AS, but again not at the client. With an AAT, that means making sure you use the right AAT for the current RqP. With the PCT, the same condition applies: you only present the PCT associated with this RqP (and the claims the PCT represents). In both cases, it’s up to a multi-user client to manage its relationship with the RqP, and it’ll do so however it best sees fit. The client could do this binding to the “current RqP" on its side through authentication, or assuming it’s a single-user program (like a mobile app), or any number of other session management mechanisms. It’s not up to UMA to decide how it happens, but UMA does depend on it in exactly the same way that OAuth doesn’t say a word about how the client manages its connection to the RO, but depends on the client managing that connection.
So in the end, it’s exactly the same requirement and assumptions as before: before the client sends a token that ostensibly represents the RqP (either the AAT or PCT), it needs to be sure it’s sending the right token for the right RqP. The only difference here is that we’re explicitly spelling it out as a requirement instead of leaving it as implicit. I couldn’t find specific text in the OAuth RFCs dealing with this, but maybe someone else will have better luck searching.
Hope this clears things up on that point.
Also, note that the set math around the claims (from the PCT, pushed by client, and gathered interactively) is completely separate from and orthogonal to the set math around the scopes. Be careful not to conflate the two!
— Justin
On Sep 29, 2016, at 4:24 PM, Eve Maler <eve@xmlgrrl.com> wrote:
http://kantarainitiative.org/confluence/display/uma/UMA+tele con+2016-09-29 MinutesRoll call
Quorum was not reached. Approve minutes
Approve minutes of UMA telecon 2016-09-22 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-09-22> : Deferred. Work on UMA.next issues
We're wondering about the "authorization process" language in the new PCT definition. Instead of the three phases, we think a flowchart showing all of the AS responses to the client's request at the token endpoint (need_info and so on), and what the client has to do after that. E.g., if the client gets success and can then successfully access the resource, that's not "phase 3" but rather a successful singular termination of an "authorization process" and we should talk about it in that language. That's way more precise than just vaguely talking about "authorization process" without stating when such a thing starts and ends.
The definition also needs to expand mentions of AS and so on, as we don't use the abbreviations in the spec.
*AI:* Domenico and Eve: D to create a beautiful flow chart according to the current draft spec for slideware purposes and E to create an ASCII version for spec purposes.
The current definition: "A correlation handle that represents a set of claims and interactions between the AS and the RqP/client pair during one authorization process to be used during future authorization processes. This MAY represent claims gathered interactively or pushed from the client. This MAY also represent any interactions the AS has with the RqP during this process, including any gathering of consent or authorization in any meaningful way. In short, this represents the sum total of the authorization process that a client went through to get its RPT (or even just trying to get its RPT). It’s intended to be used when this client gets a new RPT for this RqP at this AS, whether or not for the same resource or resource set and possibly for different policies or resource owners alltogether."
A potential way to change it: "A correlation handle that represents a set of claims and interactions between the authorization server and the requesting party/client pair during one authorization process to be used during future authorization processes. This represents a set of claims and/or interactions; the authorization server MAY have gathered the claims interactively or the client MAY have pushed them, and an end-user requesting party MAY have provided consent or authorization in some fashion to the authorization server for persisting this information across authorization processes."
Eve suggests moving the following text to Sec 1.3.2, where the conceptual explanation of the AAT used to be and where the conceptual explanation of the PCT kind of goes now: "The PCT represents the sum total of the authorization process that a client and its requesting part went through to obtain its RPT (or even just trying to get its RPT). It is intended to be used when this client obtain a new RPT for this requesting party at this authorization server, whether or not for the same resource set and possibly for different policies or resource owners."
Looking at the name of the UMA grant, why "uma-ticket"? Is it because we have a "ticket pattern"? Okay.
The PCT text in Sec 3.5.1 has us a bit confounded: "In circumstances where the authorization server returned an PCT previously when returning an RPT, the client MAY include the PCT. The PCT MAY have been obtained for a different resource at this AS, but since the PCT likely represents claims from the RqP it MUST be associated with the current RqP to the best of the client's abilities to determine this."
Let's unpack this. In the OAuth-based AAT solution, authentication would have been required, and the client would known for a certainty whether it was the same RqP. Now, it doesn't know for sure. Plus, if it's requesting access to a different resource, the policies and therefore trust elevation requirements could be different; hence, whatever package of claims and/or interactions might be different. The client can't know a priori. But the PCT is meant to be associated with "the same RqP" as far as the client is concerned, regardless of whatever trust elevation is required on the AS side, and regardless of whatever the AS requires, don't all clients pretty much require some kind of authentication for their own purposes? So couldn't any client do correlation of PCTs with their own users with 100% certainty?
*AI:* Eve: Get Justin's input on our analysis and questions.
In Sec 3.5.2, the first appearance of set math is hinted at: "The authorization server evaluates the policies in light of claims gathered from the client. These claims MAY be pushed directly by the client using the claim_tokens parameter, MAY be gathered interactively at the interactive claims gathering endpoint, and MAY be *represnted* by the persisted claims token (PCT) present by the client in the pct *paramter*. The authorization server MAY combine claims from these sources in any manner it chooses, though a simple union of all claims is reasonable."
(Note and fix typos.)
James had proposed set math as follows:
(ASDefaultClientScopes UNION ClientRequestScopes UNION PermissionTicketScopes) SUPER_SET_OR_EQUAL_TO PermissionTicketScopes
The questions for the spec are:
- What does the RS have to do at API publication time, if anything? - There *will* be scopes published, whether in informal fashion or, say, Swagger (machine-readable) - Nothing much more to say about this, probably (we have some editorial notes on it) - What does the client have to do at scope registration time, if anything? - It's never required for a client to register for scopes, but it could; this would limit what's possible for it to handle (we have some editorial notes on it) - *What does the RS have to do at permission ticket registration time?* - In UMA1, we've said it must register at least what the client attempted to access, but Justin has proposed letting it register any number of scopes, more/less/other - This remains to be fully discussed, though we started it at CIS - *Can the client request scopes from the RS (in addition to just attempting access)?* (added after the call: see George's comments from 2016-08-04 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-08-04> about efficiency of client communications for smart clients) - What does the client have to do at RPT request time? - *How does the client request scopes from the AS, and what can it ask for (e.g., what interaction does it have if it wants multiple resource sets)?* - In UMA1, the client couldn't ask for anything explicitly, but Justin's MPD exploration has made it possible (though not required) for the client to request scopes and we've agreed to make this possible - What does the AS have to do at RPT issuance time? - In UMA1, we've said the AS can issue a partial set of scopes if policy is only partially satisfied – are we still okay with that? We haven't discussed it - There are circumstances where only full matching will do (say, enterprise), and others where partial satisfaction would be good (consumer)
Spec instructions:
- See above!
Attendees
As of 31 Aug 2016, quorum is 6 of 10. (Domenico, Sal, Nagesh, Andi, Robert, Maciej, Eve, Jeffrey, Mike, Sarah)
1. Domenico 2. Sal 3. Nagesh 4. Robert 5. Eve
Non-voting participants:
- Andrew - Scott F - Kathleen - James
Regrets:
- Mike - John W - Andi
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
_______________________________________________ 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
It’s always best effort because the client decides what it means to know the same RqP is there. Say you’ve got a single-user mobile application — the client is probably going to always assume that it’s the same user and therefore always send the PCT, even if the user never authenticates to the client software itself. I feel that trying to tie down RqP identity as known to the client is going to be a losing battle. Better to have the client do the best they can to see that the RqP is the same one they expect it to be. FWIW, OAuth clients already need to do exactly the same thing when presenting access tokens on behalf of user actions. From a developer’s perspective, the same logic applies. — Justin
On Oct 3, 2016, at 2:57 PM, Andrew Hughes <andrewhughes3000@gmail.com> wrote:
Justin - does that mean that the client shouldn't use a 'best effort' to ensure that they have the same RqP present. They must be positive that it is the same RqP.
One possible mechanism might be to match a client-side authentication of the RqP to some identifier in the PCT?
Because the PCT is a set of claims about the RqP, not a set of 'authorization decision results' at the AS. The AS might have to evaluate authorization policy again using the AS-stored claims referenced by the PCT. andrew.
Andrew Hughes CISM CISSP Independent Consultant In Turn Information Management Consulting
o +1 650.209.7542 m +1 250.888.9474 1249 Palmer Road, Victoria, BC V8P 2H8 AndrewHughes3000@gmail.com <mailto:AndrewHughes3000@gmail.com> ca.linkedin.com/pub/andrew-hughes/a/58/682/ <http://ca.linkedin.com/pub/andrew-hughes/a/58/682/> Identity Management | IT Governance | Information Security
On Mon, Oct 3, 2016 at 11:47 AM, Justin Richer <jricher@mit.edu <mailto:jricher@mit.edu>> wrote: Oh, and to answer the embedded question:
What if the client goes back to the identical resource but the client is being wielded by a different RqP this time? What is the client's responsibility and how should it handle it?
In my view, the client MUST NOT present a PCT that was gathered while the client was being wielded by a different RqP. The claims represented by the PCT no longer represent the current user of the client.
— Justin
On Oct 3, 2016, at 2:41 PM, Justin Richer <jricher@MIT.EDU <mailto:jricher@mit.edu>> wrote:
The point is that it doesn’t matter whether the client is accessing the same resource or not. That part is immaterial, and I think my inclusion of the text in the definition was misleading. The intended meaning of the text doesn’t change when you pull that part out entirely:
If the authorization server previously returned a PCT along with an RPT, the client MAY include the PCT in order to optimize the process of seeking a new RPT. Given that a PCT represents a set of requesting party claims, the client MUST make a best effort to ensure that it is associated with the same requesting party as previously.
Does this make it clearer? Just wanted to point out that it isn’t tied to the resource.
— Justin
On Oct 3, 2016, at 1:45 AM, Eve Maler <eve@xmlgrrl.com <mailto:eve@xmlgrrl.com>> wrote:
Okay, on that latter issue, working on the spec just now I think I may have broken the code, so to speak. The concern is that the set of claims represented by the PCT may not be identical to what the client currently thinks it knows about the current RqP -- right?
Here's the brute-force formulation I'm trying in Sec 3.5.1...
"If the authorization server previously returned a PCT along with an the RPT, the client MAY include the PCT in order to optimize the process of seeking a new RPT. Given that a PCT represents a set of requesting party claims, even if this PCT were obtained in the course of seeking access to a different resource or the same resource at a time when different resource owner policies applied, the client MUST make a best effort to ensure that it is associated with the same requesting party as previously."
This helped me. Did I get it right? If so, did it help enough other people? Would it be worth adding "...a set of requesting party claims asked for by the authorization server"?
(I think I can get to a couple more edits before publishing draft -03 sometime Monday.)
Eve Maler Cell +1 425.345.6756 <tel:%2B1%20425.345.6756> | Skype: xmlgrrl | Twitter: @xmlgrrl
On Sun, Oct 2, 2016 at 10:18 PM, Eve Maler <eve@xmlgrrl.com <mailto:eve@xmlgrrl.com>> wrote: Regarding claim combining, the more I think about it, I don't think we can really say too much. Claims (in band) are one thing and policy conditions (out of band) are another.
Any claims collected are, I think, just pieces of information in a flat space as far as UMA's "native claims data model" is concerned (so maybe we could go as far as saying that, while maybe pointing off to the extensibility section if you want to do more). On the other hand, policy expression models and engines could be arbitrarily sophisticated in what they do with that information: You have to be A, and not-B, and can optionally be C, and so on.
====
Regarding PCT care and feeding on the client side, I had been figuring that "persisted representation" of its user was at the heart of it, not leading language. I'm still not getting why the PCT having been issued on a visit to a different resource is so key. What if it were a visit to the same resource whose operative policies had changed or something? The really important thing is: What if the client goes back to the identical resource but the client is being wielded by a different RqP this time? What is the client's responsibility and how should it handle it?
Eve Maler Cell +1 425.345.6756 <tel:%2B1%20425.345.6756> | Skype: xmlgrrl | Twitter: @xmlgrrl
On Fri, Sep 30, 2016 at 6:21 AM, Justin Richer <jricher@mit.edu <mailto:jricher@mit.edu>> wrote:
On Sep 29, 2016, at 11:32 PM, Eve Maler <eve@xmlgrrl.com <mailto:eve@xmlgrrl.com>> wrote:
Regarding "math" of claims vs. scopes: Yes, of course, you're right, I think I got overexcited seeing we were getting near policy-matching. :-) In any case, I think we're close to getting back onto that topic.
Do we actually need to be saying "The authorization server MAY combine claims from these sources in any manner it chooses, though a simple union of all claims is reasonable."? On the one hand, what would happen if we said nothing (since the statement is non-testable)? On the other hand, what if someone wanted to create an extension trust elevation mechanism that added logical operators for claims gathering, indicating that some were optional and, if supplied, could be used at will or something?
Possibly needs to be more robust like that. I erred on the side of simplicity and based on my implementation: just smash all the things together. I think at the very least guidance to developers is a good idea otherwise we’re going to get mismatched expectations from clients presenting PCTs.
====
Regarding this text -- "The PCT MAY have been obtained for a different resource at this AS, but since the PCT likely represents claims from the RqP it MUST be associated with the current RqP to the best of the client's abilities to determine this." -- and the question of RqP matching:
So I think you're saying this was true before with AATs but we provided no guidance about it.
Correct.
And the reason you're mentioning different resources is because if it were the same resource, it would be more obviously the same RqP?
Possibly. Could be two RqPs using the same client to get the same resource, in which case it should be separate RPTs and separate PCTs. The same way an OAuth client getting a resource for two RO’s would get two access tokens and keep them separately tied to user sessions.
I feel like there's some leap being made there that I'm not quite grasping. Even if an attempt at access were being made to the "same resource" (a resource that had been accessed before by this client that had been handed a PCT and RPT, a PCT and RPT it is attempting to wield now), the client had better have done a good job of "RqP-matching" just as you're describing. I think.
Correct. What’s the leap? The requirement to match the PCT to the RqP is universal, but the PCT MAY have come from a different resource. Perhaps the sentence order should be swapped — were you reading the former part as a conditional? That’s not the intended interpretation.
Should we be saying something more like this? "If a client intends to use an issued PCT in a subsequent authorization process to represent the same requesting party, it MUST associate that PCT with its own persisted representation of that requesting party to the best of its ability.”
Something like that, avoiding “persisted representation” and other leading language of course.
— Justin
Eve Maler Cell +1 425.345.6756 <tel:%2B1%20425.345.6756> | Skype: xmlgrrl | Twitter: @xmlgrrl
On Thu, Sep 29, 2016 at 2:43 PM, Justin Richer <jricher@mit.edu <mailto:jricher@mit.edu>> wrote: A note on this comment:
Let's unpack this. In the OAuth-based AAT solution, authentication would have been required, and the client would known for a certainty whether it was the same RqP. Now, it doesn't know for sure. Plus, if it's requesting access to a different resource, the policies and therefore trust elevation requirements could be different; hence, whatever package of claims and/or interactions might be different. The client can't know a priori. But the PCT is meant to be associated with "the same RqP" as far as the client is concerned, regardless of whatever trust elevation is required on the AS side, and regardless of whatever the AS requires, don't all clients pretty much require some kind of authentication for their own purposes? So couldn't any client do correlation of PCTs with their own users with 100% certainty?
The AAT doesn’t tell the client who the RqP is any more than any other OAuth access token does. The AAT represents an authenticated user at the AS, but not at the client. The PCT might represent authentication or any number of other things at the AS, but again not at the client. With an AAT, that means making sure you use the right AAT for the current RqP. With the PCT, the same condition applies: you only present the PCT associated with this RqP (and the claims the PCT represents). In both cases, it’s up to a multi-user client to manage its relationship with the RqP, and it’ll do so however it best sees fit. The client could do this binding to the “current RqP" on its side through authentication, or assuming it’s a single-user program (like a mobile app), or any number of other session management mechanisms. It’s not up to UMA to decide how it happens, but UMA does depend on it in exactly the same way that OAuth doesn’t say a word about how the client manages its connection to the RO, but depends on the client managing that connection.
So in the end, it’s exactly the same requirement and assumptions as before: before the client sends a token that ostensibly represents the RqP (either the AAT or PCT), it needs to be sure it’s sending the right token for the right RqP. The only difference here is that we’re explicitly spelling it out as a requirement instead of leaving it as implicit. I couldn’t find specific text in the OAuth RFCs dealing with this, but maybe someone else will have better luck searching.
Hope this clears things up on that point.
Also, note that the set math around the claims (from the PCT, pushed by client, and gathered interactively) is completely separate from and orthogonal to the set math around the scopes. Be careful not to conflate the two!
— Justin
On Sep 29, 2016, at 4:24 PM, Eve Maler <eve@xmlgrrl.com <mailto:eve@xmlgrrl.com>> wrote:
http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-09-29 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-09-29> Minutes Roll call Quorum was not reached. Approve minutes Approve minutes of UMA telecon 2016-09-22 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-09-22> : Deferred. Work on UMA.next issues We're wondering about the "authorization process" language in the new PCT definition. Instead of the three phases, we think a flowchart showing all of the AS responses to the client's request at the token endpoint (need_info and so on), and what the client has to do after that. E.g., if the client gets success and can then successfully access the resource, that's not "phase 3" but rather a successful singular termination of an "authorization process" and we should talk about it in that language. That's way more precise than just vaguely talking about "authorization process" without stating when such a thing starts and ends. The definition also needs to expand mentions of AS and so on, as we don't use the abbreviations in the spec. AI: Domenico and Eve: D to create a beautiful flow chart according to the current draft spec for slideware purposes and E to create an ASCII version for spec purposes. The current definition: "A correlation handle that represents a set of claims and interactions between the AS and the RqP/client pair during one authorization process to be used during future authorization processes. This MAY represent claims gathered interactively or pushed from the client. This MAY also represent any interactions the AS has with the RqP during this process, including any gathering of consent or authorization in any meaningful way. In short, this represents the sum total of the authorization process that a client went through to get its RPT (or even just trying to get its RPT). It’s intended to be used when this client gets a new RPT for this RqP at this AS, whether or not for the same resource or resource set and possibly for different policies or resource owners alltogether." A potential way to change it: "A correlation handle that represents a set of claims and interactions between the authorization server and the requesting party/client pair during one authorization process to be used during future authorization processes. This represents a set of claims and/or interactions; the authorization server MAY have gathered the claims interactively or the client MAY have pushed them, and an end-user requesting party MAY have provided consent or authorization in some fashion to the authorization server for persisting this information across authorization processes." Eve suggests moving the following text to Sec 1.3.2, where the conceptual explanation of the AAT used to be and where the conceptual explanation of the PCT kind of goes now: "The PCT represents the sum total of the authorization process that a client and its requesting part went through to obtain its RPT (or even just trying to get its RPT). It is intended to be used when this client obtain a new RPT for this requesting party at this authorization server, whether or not for the same resource set and possibly for different policies or resource owners." Looking at the name of the UMA grant, why "uma-ticket"? Is it because we have a "ticket pattern"? Okay. The PCT text in Sec 3.5.1 has us a bit confounded: "In circumstances where the authorization server returned an PCT previously when returning an RPT, the client MAY include the PCT. The PCT MAY have been obtained for a different resource at this AS, but since the PCT likely represents claims from the RqP it MUST be associated with the current RqP to the best of the client's abilities to determine this." Let's unpack this. In the OAuth-based AAT solution, authentication would have been required, and the client would known for a certainty whether it was the same RqP. Now, it doesn't know for sure. Plus, if it's requesting access to a different resource, the policies and therefore trust elevation requirements could be different; hence, whatever package of claims and/or interactions might be different. The client can't know a priori. But the PCT is meant to be associated with "the same RqP" as far as the client is concerned, regardless of whatever trust elevation is required on the AS side, and regardless of whatever the AS requires, don't all clients pretty much require some kind of authentication for their own purposes? So couldn't any client do correlation of PCTs with their own users with 100% certainty? AI: Eve: Get Justin's input on our analysis and questions. In Sec 3.5.2, the first appearance of set math is hinted at: "The authorization server evaluates the policies in light of claims gathered from the client. These claims MAY be pushed directly by the client using the claim_tokens parameter, MAY be gathered interactively at the interactive claims gathering endpoint, and MAY be represnted by the persisted claims token (PCT) present by the client in the pct paramter. The authorization server MAY combine claims from these sources in any manner it chooses, though a simple union of all claims is reasonable." (Note and fix typos.) James had proposed set math as follows: (ASDefaultClientScopes UNION ClientRequestScopes UNION PermissionTicketScopes) SUPER_SET_OR_EQUAL_TO PermissionTicketScopes The questions for the spec are: What does the RS have to do at API publication time, if anything? There will be scopes published, whether in informal fashion or, say, Swagger (machine-readable) Nothing much more to say about this, probably (we have some editorial notes on it) What does the client have to do at scope registration time, if anything? It's never required for a client to register for scopes, but it could; this would limit what's possible for it to handle (we have some editorial notes on it) What does the RS have to do at permission ticket registration time? In UMA1, we've said it must register at least what the client attempted to access, but Justin has proposed letting it register any number of scopes, more/less/other This remains to be fully discussed, though we started it at CIS Can the client request scopes from the RS (in addition to just attempting access)? (added after the call: see George's comments from 2016-08-04 <http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2016-08-04> about efficiency of client communications for smart clients) What does the client have to do at RPT request time? How does the client request scopes from the AS, and what can it ask for (e.g., what interaction does it have if it wants multiple resource sets)? In UMA1, the client couldn't ask for anything explicitly, but Justin's MPD exploration has made it possible (though not required) for the client to request scopes and we've agreed to make this possible What does the AS have to do at RPT issuance time? In UMA1, we've said the AS can issue a partial set of scopes if policy is only partially satisfied – are we still okay with that? We haven't discussed it There are circumstances where only full matching will do (say, enterprise), and others where partial satisfaction would be good (consumer) Spec instructions: See above! Attendees As of 31 Aug 2016, quorum is 6 of 10. (Domenico, Sal, Nagesh, Andi, Robert, Maciej, Eve, Jeffrey, Mike, Sarah) Domenico Sal Nagesh Robert Eve Non-voting participants: Andrew Scott F Kathleen James Regrets: Mike John W Andi
Eve Maler Cell +1 425.345.6756 <tel:%2B1%20425.345.6756> | Skype: xmlgrrl | Twitter: @xmlgrrl
_______________________________________________ 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 (3)
-
Andrew Hughes -
Eve Maler -
Justin Richer