Draft minutes of ad hoc UMA telecon 2017-08-08

8 Aug 2017

      Attending:

   - Eve
   - Cigdem
   - Mike
   - Sal

Non-voting participants:

   - James
   - Justin

We have quorum for this call.

#352 https://github.com/KantaraInitiative/wg-uma/issues/352:

James notes that only the resource registration endpoint needs the PAT,
because at that time you don't yet have resource IDs (which carry resource
owner context); the other two protection API endpoints involve resource
IDs, which could convey the necessary RO context and could use the client
credentials grant instead, avoiding the need for ROs to refresh PATs. But
for anyone who hates "forever tokens" of whatever sort, they will have to
bother users. That's the tradeoff. Justin opines that using the client
credentials grant is tantamount to using an API key.

Eve suggested to a colleague who brought up this challenge: "The PAT does
need to serve as an "offline" type of OAuth access token (which is a
typical situation for them, perhaps the preponderant one). We've only given
guidance that the RS has to manage TTL to ensure the outcome of keeping the
PAT alive; see the FedAuthz spec
https://docs.kantarainitiative.org/uma/ed/oauth-uma-federated-authz-2.0-06.h...
and
the HEART profile
http://openid.net/specs/openid-heart-uma-1_0-2017-05-31.html#rfc.section.3.3....
If the RS can't get a permission ticket, it gives this error
https://docs.kantarainitiative.org/uma/ed/oauth-uma-grant-2.0-06.html#permis...:
a 403 Forbidden and "Warning: 199 - "UMA Authorization Server Unreachable".
The RS could then, in the "competitive space", take this opportunity to
initiate some refreshing action such as send a notification to the RO and
ask them to re-consent to the pairing with the AS. Does that sound like a
reasonable approach? If so, worth describing in the UMA Implementer's Guide
http://kantarainitiative.org/confluence/display/uma/UMA+Implementer%27s+Guid...
?"

Cigdem points out that the PAT represents the RO's agreement for the RS to
serve in this role with the AS's various endpoints, and it doesn't seem
right to protect its various endpoints in different ways. Eve points out
that this is relevant to the legal framework effort, since we're mapping
technical artifacts to legal devices right now. The RO could revoke the PAT
and that would mean the RO doesn't want the RS to use that AS for those
resources anymore. James: Good point.

Since this has been brought up, it seems, multiple times  we should go back
to saying a bit more in FedAuthz Sec 5.1, e.g. provide rationale and point
to the UIG for some suggestions about what to do.

*We have consensus for no change, but enhancing the explanation
(editorial).*

(Note to Legal subgroup denizens: We should look at drawing a line between
Grant and FedAuthz, for hygiene. PAT is FedAuthz only.)

#341 https://github.com/KantaraInitiative/wg-uma/issues/341:

Eve's proposal: Keep the MUST, so that the AS always hands out a ticket,
and provide some UIG suggestions about "competitive space" options for
hinting. Justin points out that the client always has the choice anyway to
discard the ticket and treat things as "terminal", doing a fresh resource
request later (even immediately later). James would like a standard way of
saying "Don't try again until...."

Do we need to invent that hinting mechanism? If we do, Justin (and Eve)
still advocate that the ticket be a MUST. Justin points to the OAuth for
Devices spec, which has a hinting parameter we could make use of: interval
https://tools.ietf.org/html/draft-ietf-oauth-device-flow-06#section-3.2
(suitably
revised to change from a device code to the rotated permission ticket, and
the semantic lines up really closely). Or we could use something like nbf a
la JWT, though the semantic is a bit more distant and we don't have
implementation experience with it for this purpose. We like keeping hints
OPTIONAL.

We should also add security considerations text to Grant Sec 5.6
https://docs.kantarainitiative.org/uma/ed/oauth-uma-grant-2.0-06.html#ticket...,
explaining that given that request_submitted use cases involve polling
intervals, the ticket has to last long enough to give the client a chance
to poll. Also, text should be added to Grant Sec 3.3.6 pointing to Sec 5.6
and mentioning that the ticket might last longer in this case because of
the requirements of the request submission to the RO.

#343 https://github.com/KantaraInitiative/wg-uma/issues/343: Should we
just mention the OAuth errors, or explicitly list them? Eve would like to
list them for searching purposes. The OAuth for Devices
https://tools.ietf.org/html/draft-ietf-oauth-device-flow-06#section-3.5
spec (Sec 3.5) just calls out to the OAuth codes. This seems sufficient. We
have consensus.

#344 https://github.com/KantaraInitiative/wg-uma/issues/344: We agree
with the thread conclusion. These are editorial instructions.

#345 https://github.com/KantaraInitiative/wg-uma/issues/345: Justin says
it's not invalid_request as Eve argued in the issue thread, it's actually
invalid_grant because the bits and bobs of the grant request were wrong.
This is an original OAuth "Bad Request" rationale. And of course the AS is
supposed to document its claim token formats supported in its metadata. Is
this worth pointing out explicitly as an example? Alternatively, a
need_info/required_claims?claim_token_format hint could be given, if the AS
and client have an understanding about hinting. Also, keep in mind that
errors can leak information to attackers, and clients need to be treated as
largely untrusted (they only have client credentials right up until they
get RPTs (at which point they are only partially trusted).

If someone forced us to choose between invalid_grant and need_info, what
would you choose? In other words, if we want to list out "invalid claim
token format" as one of the conditions under a specific one of the error
codes, which error code should it be listed under? We have converged on
need_info?required_claims/claim_token_format. This gives the exact data the
client needs in the most helpful packaging (an error description could
still be supplied). *We have consensus.*

*AI:* Eve: Book one more ad hoc UMA telecon next Tuesday at 7am PT/9am
CT/10am ET/3pm UK/4pm CET.

*AI:* Eve: Send emails about the remaining issues and send out revs 07 for
review by the ad hoc.

*Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

Eve Maler

Eve Maler

tags

participants (1)