...
Rough consensus: We think Option 1 is starting to "leave the table" and be less viable: it has little inherent rationale, vs. Option 2's efficiency rationale, and the current state of affairs doesn't fully avoid endpoint-overloading anyway. However, we can't force a full conclusion until we come up with a proposal for a replacement singular authorization data endpoint that accounts for the other outstanding 88/99 issues as well.
Single-RS vs. multi-RS RPT:
- spec is clear on single-RS but not on ticket-based lazy RS binding mechanism
- keep current text, add text explaining mechanism, add option for host ID-based eager RS binding mechanism, switch to eager mechanism only, other?
...
Some very rough feedback is to add text explaining the lazy binding mechanism to the text. We will continue discussing. Mike suggests simplifying where possible.
RPT expires_at:
- keep, remove, make optional with default, other?
- clarify semantics of RPT identifier and associated permissions when RPT gets "refreshed"?
...