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/