On 23/10/2018 20:44, Jim Schaad wrote:
-----Original Message----- From: Ludwig Seitz <[email protected]>
Sent: Tuesday, October 23, 2018 7:43 AM To: Jim Schaad
<[email protected]>; draft-ietf-ace-oauth- [email protected] Cc:
[email protected] Subject: Re: [Ace] WGLC for draft-ietf-ace-authz
Hallo Jim,
thank you for the review! Comments inline.
/Ludwig
On 22/10/2018 21:09, Jim Schaad wrote:
* Section 5.8.1 - What is the purpose of creating an identifier
for a token? Is this supposed to be used rather than the one from
the AS for something like shared secret TLS? Note that this is
an unprotected value.
AFAIK cti is not a mandatory claim of an access token, thus a RS
might want to create an identifier for tokens that do not have a
cti.
Ok - so the client has this cti - what could it use it for?
You might want to treat the token as a RESTful resource under
/authz-info that the client can GET or DELETE using the cti as part of
the URI.
I admit this is never explicitly stated and would need to be worked out
quite a bit (as Steffi remarked, there would need to be access control
on the tokens), so I wouldn't argue against removing the comment from
the draft altogether.
* Section 5.8.1 - If the token is "not valid" is the RS required
(i.e. MUST) to try introspection before returning a response if
the RS does introspection? The text currently says MAY. If this
is really MAY then the text should say that the token is always
successfully accepted by the RS.
I'm not sure I understand the issue. Introspection is optional in
general, and may be required in specific use cases. If the RS
determines that the token is not valid on its own, why would it
want to do introspection on top of this?
The RS has just received a token. The RS wants to validate said
token. It can do it on its own or it can do it with introspection.
If it is going to do it with introspection can it defer this
validation until first use or does it need to do it immediately so it
is not going to store an invalid token? It is possible that an RS is
going to both support some tokens and require introspection on
others. In that case it would decide the token was not valid, but
would not necessarily know if it was a legal introspection token.
I'm not convinced we need to REQUIRE a certain behavior here. I would
however agree to put some text in the draft outlining these options and
analyzing the resulting security implications.
Would that address your comment sufficiently?
/Ludwig
--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
