Re: [Ace] WGLC for draft-ietf-ace-authz

[Ludwig Seitz <[e-mail]>]

On 23/10/2018 20:44, Jim Schaad wrote:
> 
> 
>> -----Original Message----- From: Ludwig Seitz <[e-mail]> 
>> Sent: Tuesday, October 23, 2018 7:43 AM To: Jim Schaad
>> <[e-mail]>; draft-ietf-ace-oauth- [e-mail] Cc:
>> [e-mail] 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 [phone]