Comments on "Saved Consent Token"
Hi all, Here are some considerations/comments about SCT (Saved Consent Token): 1. SCT could be considered as session token or session identifier for managing RqP/Client interactions with AS for the trust elevation process, for keeping transparent the subsequent actions. The use case is when Bob (RqP) attempts to access to a protected resouce, obtaining a RPT+SCT. Later (10 min), when he tries to access to a new protected resource which match the previouse claims policy, having an active session (on AS), the client posts the SCT which proof that he has previously released the claims, avoiding the claims gathering again. 2. As session identifier token, it should follow the three rules: unique, random and encrypted. Validity is important as well. 3. Maybe the name "Saved consent Token" could be confusing because of "consent" word, which recall compliance terminology. I hope this is helpful for the discussion. Domenico Sent from my iPad
Thanks very much for these thoughts, Domenico! At first I was thinking of this as "session consent" at the AS for interaction too, but when I looked back at Justin's original description after our call discussion, it was meant more for replacing the original AAT design, which was mainly meant to cover the use of the RPT endpoint through OAuth consent (and technically could *only* cover consent to use the RPT endpoint and not the claims-gathering endpoint, I think). So the way it's currently written, the SCT consent is supposed to grant consent for subsequently *client-pushed* claims rather than any interactions, and thus it's not so much a session token in traditional terms as a consent-based persistence. (Justin was calling it a refresh token, but I was concerned about confusion with both the real refresh token that may be present, and with the fact that it's not a "token" -- it's more like a ticket. In fact, maybe we should literally call it a consent ticket or something?? Except that it doesn't rotate?????) Agreed about "consent" being a touchy word. Maybe borrow "authorization" directly from OAuth? *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Thu, Aug 25, 2016 at 7:00 AM, Domenico Catalano < domenico.catalano@oracle.com> wrote:
Hi all,
Here are some considerations/comments about SCT (Saved Consent Token):
1. SCT could be considered as session token or session identifier for managing RqP/Client interactions with AS for the trust elevation process, for keeping transparent the subsequent actions. The use case is when Bob (RqP) attempts to access to a protected resouce, obtaining a RPT+SCT. Later (10 min), when he tries to access to a new protected resource which match the previouse claims policy, having an active session (on AS), the client posts the SCT which proof that he has previously released the claims, avoiding the claims gathering again.
2. As session identifier token, it should follow the three rules: unique, random and encrypted. Validity is important as well.
3. Maybe the name "Saved consent Token" could be confusing because of "consent" word, which recall compliance terminology.
I hope this is helpful for the discussion. Domenico
Sent from my iPad _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
I hope we can avoid any use of "consent" in UMA. If we can't, then let's make sure we have a clear definition of consent. As for the more substantive aspect of the discussion, it's difficult to capture Alice's policy at the RqP level because, in many cases, access control is granted at the client level. For example, it would be unusual to authorize a particular employee to access a credit report resource or a particular doctor to access a health record resource. In other cases, like a dating service, granting all possible users of the client the same access could be disastrous. UMA does not provide adequate guidance on how this should be handled. In our current HIE of One update Michael Chen and I are trying to figure out what makes sense for the health information exchange use-case. Our current thinking is that if Dr. Bob is the first RqP to register a Client (a hospital's EHR) then any other RqPs using the same Client can expect the same scope of access. However, we also log all of the actual RqPs that receive authorization and allow Alice to set policies for RqPs to the extent the trust elevation process can support them. Are we on the right track? Adrian On Fri, Aug 26, 2016 at 6:00 PM, Eve Maler <eve@xmlgrrl.com> wrote:
Thanks very much for these thoughts, Domenico!
At first I was thinking of this as "session consent" at the AS for interaction too, but when I looked back at Justin's original description after our call discussion, it was meant more for replacing the original AAT design, which was mainly meant to cover the use of the RPT endpoint through OAuth consent (and technically could *only* cover consent to use the RPT endpoint and not the claims-gathering endpoint, I think).
So the way it's currently written, the SCT consent is supposed to grant consent for subsequently *client-pushed* claims rather than any interactions, and thus it's not so much a session token in traditional terms as a consent-based persistence. (Justin was calling it a refresh token, but I was concerned about confusion with both the real refresh token that may be present, and with the fact that it's not a "token" -- it's more like a ticket. In fact, maybe we should literally call it a consent ticket or something?? Except that it doesn't rotate?????)
Agreed about "consent" being a touchy word. Maybe borrow "authorization" directly from OAuth?
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
On Thu, Aug 25, 2016 at 7:00 AM, Domenico Catalano < domenico.catalano@oracle.com> wrote:
Hi all,
Here are some considerations/comments about SCT (Saved Consent Token):
1. SCT could be considered as session token or session identifier for managing RqP/Client interactions with AS for the trust elevation process, for keeping transparent the subsequent actions. The use case is when Bob (RqP) attempts to access to a protected resouce, obtaining a RPT+SCT. Later (10 min), when he tries to access to a new protected resource which match the previouse claims policy, having an active session (on AS), the client posts the SCT which proof that he has previously released the claims, avoiding the claims gathering again.
2. As session identifier token, it should follow the three rules: unique, random and encrypted. Validity is important as well.
3. Maybe the name "Saved consent Token" could be confusing because of "consent" word, which recall compliance terminology.
I hope this is helpful for the discussion. Domenico
Sent from my iPad _______________________________________________ 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
-- Adrian Gropper MD PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/
I’d like to propose that we call this instead the “Persisted Claims Token”, as this represents what’s often going on under the hood. I know that the intent of the AAT was originally to represent the consent of the RqP for using the client, but I would argue that the AAT never truly fulfilled that promise in all cases, as we’ve discussed on the calls and on the list previously. Therefore, I would argue that its functional replacement really doesn’t capture consent any better. What it’s doing instead is representing to the AS that this client has previously submitted a bunch of claims to the AS (directly or interactively, doesn’t matter), that these claims were accepted, and that the same client can then return this token to represent that set of claims previously accepted. The client presenting this basically says “you already know a bunch of claims that I’ve presented, you can use those to make this decision”. The PCT is a semi-bearer token as it is linked to the client ID and client credentials (secret or key or what have you) if applicable. It’s up to the client to present the right PCT for the right user in multi-user situations like a website client, and it’s up to the AS to make sure the PCT is tied to the client. All of this is in parallel to the refresh token in OAuth. What’s not quite parallel is that the PCT represents that claims were submitted, but not necessarily that a given access token was granted. In other words, a client can use a PCT to get a *different* access token, assuming the claims are sufficient to fulfill the policies. Thoughts? Naming things is hard, — Justin
On Aug 27, 2016, at 1:00 AM, Eve Maler <eve@xmlgrrl.com> wrote:
Thanks very much for these thoughts, Domenico!
At first I was thinking of this as "session consent" at the AS for interaction too, but when I looked back at Justin's original description after our call discussion, it was meant more for replacing the original AAT design, which was mainly meant to cover the use of the RPT endpoint through OAuth consent (and technically could only cover consent to use the RPT endpoint and not the claims-gathering endpoint, I think).
So the way it's currently written, the SCT consent is supposed to grant consent for subsequently client-pushed claims rather than any interactions, and thus it's not so much a session token in traditional terms as a consent-based persistence. (Justin was calling it a refresh token, but I was concerned about confusion with both the real refresh token that may be present, and with the fact that it's not a "token" -- it's more like a ticket. In fact, maybe we should literally call it a consent ticket or something?? Except that it doesn't rotate?????)
Agreed about "consent" being a touchy word. Maybe borrow "authorization" directly from OAuth?
Eve Maler Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
On Thu, Aug 25, 2016 at 7:00 AM, Domenico Catalano <domenico.catalano@oracle.com <mailto:domenico.catalano@oracle.com>> wrote: Hi all,
Here are some considerations/comments about SCT (Saved Consent Token):
1. SCT could be considered as session token or session identifier for managing RqP/Client interactions with AS for the trust elevation process, for keeping transparent the subsequent actions. The use case is when Bob (RqP) attempts to access to a protected resouce, obtaining a RPT+SCT. Later (10 min), when he tries to access to a new protected resource which match the previouse claims policy, having an active session (on AS), the client posts the SCT which proof that he has previously released the claims, avoiding the claims gathering again.
2. As session identifier token, it should follow the three rules: unique, random and encrypted. Validity is important as well.
3. Maybe the name "Saved consent Token" could be confusing because of "consent" word, which recall compliance terminology.
I hope this is helpful for the discussion. Domenico
Sent from my iPad _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org <mailto:WG-UMA@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/wg-uma <http://kantarainitiative.org/mailman/listinfo/wg-uma>
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
Okay...I think I'm confused then, as this doesn't match your original description of your idea: "One of the questions is how do we capture RqP consent in MPD? I argue that it can be done easily at the interactive claims gathering endpoint. Here, the AS can ask the RqP if they consent to allowing the client to submit claims directly on their behalf or not." ...and may more closely match where Domenico was going with his description. At first, I tried to spec something like the latter, but then referred back to your original description and changed it to the former. So first, I think we need to be really clear about what sort of persistence we want this thingie to represent (it could be multiple kinds, e.g. authorization for interactive claims just gathered and also future claims about to be pushed...), and then we can name it. By the way, I *still* don't understand why the AAT couldn't have represented the RqP's consent (or, if you want to avoid the "c word", authorization) for the client to send claims to the AS. We might have overstated it in Core Sec 1.3.2 <https://docs.kantarainitiative.org/uma/rec-uma-core-v1_0_1.html#authorization-api> because we went outside the one endpoint: "The issuance of an AAT represents the approval of this requesting party for this client to engage with this authorization server to supply claims, ask for authorization, and perform any other tasks needed for obtaining authorization for access to resources at all resource servers that use this authorization server." But the point of OAuth, and its valid access token, is to represent the user's (OAuth RO's) authorization for the (OAuth) client to access the granted scopes of access at the (OAuth) RS protected by the (OAuth) AS. The roles here are: OAuth RO=UMA RqP, OAuth client=UMA client, OAuth RS=UMA AS's authorization API (narrowly defined, the RPT endpoint), and OAuth AS=UMA AS's OAuth protection over its RPT endpoint. What about the AAT as an ordinary token, issued according to an ordinary OAuth process, doesn't meet that bar? *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl On Wed, Aug 31, 2016 at 6:04 AM, Justin Richer <jricher@mit.edu> wrote:
I’d like to propose that we call this instead the “Persisted Claims Token”, as this represents what’s often going on under the hood.
I know that the intent of the AAT was originally to represent the consent of the RqP for using the client, but I would argue that the AAT never truly fulfilled that promise in all cases, as we’ve discussed on the calls and on the list previously. Therefore, I would argue that its functional replacement really doesn’t capture consent any better.
What it’s doing instead is representing to the AS that this client has previously submitted a bunch of claims to the AS (directly or interactively, doesn’t matter), that these claims were accepted, and that the same client can then return this token to represent that set of claims previously accepted. The client presenting this basically says “you already know a bunch of claims that I’ve presented, you can use those to make this decision”.
The PCT is a semi-bearer token as it is linked to the client ID and client credentials (secret or key or what have you) if applicable. It’s up to the client to present the right PCT for the right user in multi-user situations like a website client, and it’s up to the AS to make sure the PCT is tied to the client. All of this is in parallel to the refresh token in OAuth.
What’s not quite parallel is that the PCT represents that claims were submitted, but not necessarily that a given access token was granted. In other words, a client can use a PCT to get a *different* access token, assuming the claims are sufficient to fulfill the policies.
Thoughts?
Naming things is hard, — Justin
On Aug 27, 2016, at 1:00 AM, Eve Maler <eve@xmlgrrl.com> wrote:
Thanks very much for these thoughts, Domenico!
At first I was thinking of this as "session consent" at the AS for interaction too, but when I looked back at Justin's original description after our call discussion, it was meant more for replacing the original AAT design, which was mainly meant to cover the use of the RPT endpoint through OAuth consent (and technically could *only* cover consent to use the RPT endpoint and not the claims-gathering endpoint, I think).
So the way it's currently written, the SCT consent is supposed to grant consent for subsequently *client-pushed* claims rather than any interactions, and thus it's not so much a session token in traditional terms as a consent-based persistence. (Justin was calling it a refresh token, but I was concerned about confusion with both the real refresh token that may be present, and with the fact that it's not a "token" -- it's more like a ticket. In fact, maybe we should literally call it a consent ticket or something?? Except that it doesn't rotate?????)
Agreed about "consent" being a touchy word. Maybe borrow "authorization" directly from OAuth?
*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
On Thu, Aug 25, 2016 at 7:00 AM, Domenico Catalano < domenico.catalano@oracle.com> wrote:
Hi all,
Here are some considerations/comments about SCT (Saved Consent Token):
1. SCT could be considered as session token or session identifier for managing RqP/Client interactions with AS for the trust elevation process, for keeping transparent the subsequent actions. The use case is when Bob (RqP) attempts to access to a protected resouce, obtaining a RPT+SCT. Later (10 min), when he tries to access to a new protected resource which match the previouse claims policy, having an active session (on AS), the client posts the SCT which proof that he has previously released the claims, avoiding the claims gathering again.
2. As session identifier token, it should follow the three rules: unique, random and encrypted. Validity is important as well.
3. Maybe the name "Saved consent Token" could be confusing because of "consent" word, which recall compliance terminology.
I hope this is helpful for the discussion. Domenico
Sent from my iPad _______________________________________________ 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
The AAT represents authorization to call the RPT endpoint, not necessarily to push a particular set of claims about me to said endpoint. My original statement quoted below was trying to use your original language to convey the concept, and I think we’ve moved past that with subsequent conversations. That’s why I wanted to move this forward with the email below. If you pull back to the mechanical function that’s being enabled here, as I understand George’s use case, it’s really more about binding a set of claims that’s been presented previously either by the client or by the RqP to the AS. The purpose of this token is to avoid sending claims again (and thereby bothering the RqP again). It’s to chain multiple resource calls with the same client+RqP combination, binding the two latter parties together. I don’t see that binding as a “consent” relationship as much as it is an identification and claims-set used for fulfilling policies. That seems, to me, to be the functional purpose of the AAT (regardless of what the stated intent of the spec is). — Justin
On Aug 31, 2016, at 7:20 PM, Eve Maler <eve@xmlgrrl.com> wrote:
Okay...I think I'm confused then, as this doesn't match your original description of your idea:
"One of the questions is how do we capture RqP consent in MPD? I argue that it can be done easily at the interactive claims gathering endpoint. Here, the AS can ask the RqP if they consent to allowing the client to submit claims directly on their behalf or not."
...and may more closely match where Domenico was going with his description. At first, I tried to spec something like the latter, but then referred back to your original description and changed it to the former.
So first, I think we need to be really clear about what sort of persistence we want this thingie to represent (it could be multiple kinds, e.g. authorization for interactive claims just gathered and also future claims about to be pushed...), and then we can name it.
By the way, I still don't understand why the AAT couldn't have represented the RqP's consent (or, if you want to avoid the "c word", authorization) for the client to send claims to the AS. We might have overstated it in Core Sec 1.3.2 <https://docs.kantarainitiative.org/uma/rec-uma-core-v1_0_1.html#authorization-api> because we went outside the one endpoint:
"The issuance of an AAT represents the approval of this requesting party for this client to engage with this authorization server to supply claims, ask for authorization, and perform any other tasks needed for obtaining authorization for access to resources at all resource servers that use this authorization server."
But the point of OAuth, and its valid access token, is to represent the user's (OAuth RO's) authorization for the (OAuth) client to access the granted scopes of access at the (OAuth) RS protected by the (OAuth) AS. The roles here are: OAuth RO=UMA RqP, OAuth client=UMA client, OAuth RS=UMA AS's authorization API (narrowly defined, the RPT endpoint), and OAuth AS=UMA AS's OAuth protection over its RPT endpoint. What about the AAT as an ordinary token, issued according to an ordinary OAuth process, doesn't meet that bar?
Eve Maler Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
On Wed, Aug 31, 2016 at 6:04 AM, Justin Richer <jricher@mit.edu <mailto:jricher@mit.edu>> wrote: I’d like to propose that we call this instead the “Persisted Claims Token”, as this represents what’s often going on under the hood.
I know that the intent of the AAT was originally to represent the consent of the RqP for using the client, but I would argue that the AAT never truly fulfilled that promise in all cases, as we’ve discussed on the calls and on the list previously. Therefore, I would argue that its functional replacement really doesn’t capture consent any better.
What it’s doing instead is representing to the AS that this client has previously submitted a bunch of claims to the AS (directly or interactively, doesn’t matter), that these claims were accepted, and that the same client can then return this token to represent that set of claims previously accepted. The client presenting this basically says “you already know a bunch of claims that I’ve presented, you can use those to make this decision”.
The PCT is a semi-bearer token as it is linked to the client ID and client credentials (secret or key or what have you) if applicable. It’s up to the client to present the right PCT for the right user in multi-user situations like a website client, and it’s up to the AS to make sure the PCT is tied to the client. All of this is in parallel to the refresh token in OAuth.
What’s not quite parallel is that the PCT represents that claims were submitted, but not necessarily that a given access token was granted. In other words, a client can use a PCT to get a *different* access token, assuming the claims are sufficient to fulfill the policies.
Thoughts?
Naming things is hard, — Justin
On Aug 27, 2016, at 1:00 AM, Eve Maler <eve@xmlgrrl.com <mailto:eve@xmlgrrl.com>> wrote:
Thanks very much for these thoughts, Domenico!
At first I was thinking of this as "session consent" at the AS for interaction too, but when I looked back at Justin's original description after our call discussion, it was meant more for replacing the original AAT design, which was mainly meant to cover the use of the RPT endpoint through OAuth consent (and technically could only cover consent to use the RPT endpoint and not the claims-gathering endpoint, I think).
So the way it's currently written, the SCT consent is supposed to grant consent for subsequently client-pushed claims rather than any interactions, and thus it's not so much a session token in traditional terms as a consent-based persistence. (Justin was calling it a refresh token, but I was concerned about confusion with both the real refresh token that may be present, and with the fact that it's not a "token" -- it's more like a ticket. In fact, maybe we should literally call it a consent ticket or something?? Except that it doesn't rotate?????)
Agreed about "consent" being a touchy word. Maybe borrow "authorization" directly from OAuth?
Eve Maler Cell +1 425.345.6756 <tel:%2B1%20425.345.6756> | Skype: xmlgrrl | Twitter: @xmlgrrl
On Thu, Aug 25, 2016 at 7:00 AM, Domenico Catalano <domenico.catalano@oracle.com <mailto:domenico.catalano@oracle.com>> wrote: Hi all,
Here are some considerations/comments about SCT (Saved Consent Token):
1. SCT could be considered as session token or session identifier for managing RqP/Client interactions with AS for the trust elevation process, for keeping transparent the subsequent actions. The use case is when Bob (RqP) attempts to access to a protected resouce, obtaining a RPT+SCT. Later (10 min), when he tries to access to a new protected resource which match the previouse claims policy, having an active session (on AS), the client posts the SCT which proof that he has previously released the claims, avoiding the claims gathering again.
2. As session identifier token, it should follow the three rules: unique, random and encrypted. Validity is important as well.
3. Maybe the name "Saved consent Token" could be confusing because of "consent" word, which recall compliance terminology.
I hope this is helpful for the discussion. Domenico
Sent from my iPad _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org <mailto:WG-UMA@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/wg-uma <http://kantarainitiative.org/mailman/listinfo/wg-uma>
_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org <mailto:WG-UMA@kantarainitiative.org> http://kantarainitiative.org/mailman/listinfo/wg-uma <http://kantarainitiative.org/mailman/listinfo/wg-uma>
participants (4)
-
Adrian Gropper -
Domenico Catalano -
Eve Maler -
Justin Richer