Why is PAT used for ticket and introspection?

[mrpotes]

In section 5.1 of FedAuthz, the implication is that the PAT should be used for authorization to use the introspect endpoint. However, presumably this should really be a client credentials token for the RS, as the PAT can expire with no opportunity to obtain a new one at the point in the flow when introspection is taking place.

[mrpotes]

The same logic applies to obtaining a ticket.

[mrpotes]

Simple example:

• Alice uses accountant Bob to do her tax return via AcmeTax website.
• Alice uploads all her accounts information to AcmeTax, and goes on vacation for 1 month
• Alice's UMA PAT lifetime (via refresh token or not, it is immaterial) expires one week later
• after 2 weeks, Bob starts to do Alice's accounts, but the RS cannot create a new ticket for him, nor can it introspect any existing RPT he has for Alice

The following statement is made in section 1.4.1:

Note: The resource server generally requires access to the protection API when an end-user resource owner is not available ("offline" access). Thus, the authorization server needs to manage the PAT in a way that ensures this outcome.

However, the net effect of this is that the PAT (or its refresh token) must never expire. I do not think this is a reasonable restriction to make.

There does not seem to be any reason for the access token for tickets or introspection to need to be the PAT - the RO is communicated via the resource IDs in play. The only thing the PAT is needed for is registering resources, where the resource needs to be bound to the RO at the AS, and is an online process involving the RO, which gives the opportunity for reacquiring the token if it has expired.

[mrpotes]

This was well explained by Cigdem on one of the recent WG calls - the PAT is the mechanism to ensure that the RO continues to grant access to shared resources via the AS. If the RO revokes the PAT, the AS should stop issuing tickets, or introspecting RPTs for their registered resources.

[xmlgrrl]

Per UMA telecon 2017-08-08: No technical change, but add more of a rationale for requiring the PAT for all of the protection API endpoints, and point to the UIG for suggestions about what to do.