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