Permission lifecycle is unclear

[jricher]

The whole lifecycle of Permission Ticket objects is unclear. Their creation is detailed, as is their use, but it's not clear whether they should expire either after time or after use. Can a ticket even be re-used? Should it?

[gffletch]

Good point. If an attempt to get an RPT fails with a retrieved permissions ticket, should it be re-usable to try again later? or should the Client just try and access the resource again at a later time and get a new permissions ticket?

[xmlgrrl]

For reference: What is said about permission ticket semantics/structure is in Core Sec 3.2 (https://docs.kantarainitiative.org/uma/rec-uma-core.html#rfc.section.3.2): "The permission ticket is a short-lived opaque structure whose form is determined by the authorization server. The ticket value MUST be securely random (for example, not merely part of a predictable sequential series), to avoid denial-of-service attacks. Since the ticket is an opaque structure from the point of view of the client, the authorization server is free to include information regarding expiration time or any other information within the opaque ticket for its own consumption. When the client subsequently uses the authorization API to ask the authorization server for authorization data to be associated with its RPT, it will submit this ticket to the authorization server."

[mmachulak]

Agreed that the permission ticket lifecycle is not defined at all. However, is this something that should be clarified in the spec or should the spec only mention "the issue" and the lifecycle itself could be provided in the implementation guide or similar document?

[xmlgrrl]

Per discussion on 2015-08-13: The feedback from the implementation process is that what's in the spec is not enough. The OAuth spec has more guidance on this type of thing. Can we be more specific without saying exactly what the lifecycle is? Can it be forever or not, e.g.? Maciej will propose text.

[xmlgrrl]

As discussed in UMA telecon 2015-08-27: Justin is looking for more implementation guidance, which we're thinking should really go in the UIG rather than here. Should we include a cross-reference out? Let's do it. We will stick to language that supports the RFC 2119 normative assertions in the spec. We can close this, presuming Maciej will implement amendments made on the call.