Re: [Ace] Fwd: New Version Notification for draft-tiloca-ace-revoked-token-notification-04.txt

[Marco Tiloca <[e-mail]>]

Hi Michael,

Thank you for your feedback! Please, see some answers inline.

Best,
/Marco

On 2021-03-03 23:07, Michael Richardson wrote:
> Marco Tiloca <[e-mail]> wrote:
>      > We have recently submitted an updated version of
>      > draft-tiloca-ace-revoked-token-notification
>
>      > https://tools.ietf.org/html/draft-tiloca-ace-revoked-token-notification-04
>
> I hadn't noticed this document before.
> I will say that I'm skeptical about the use cases.
> I took a quick read through section 1.
> {If I had to make allusions to PKIX, I wonder if isn't more like an
> "OCSP"-staple than a CRL}

==>MT
In the method we propose, requests to the AS do not include a (reference 
to a) Token to validate. Instead, they ask for an indication of 
pertaining revoked Tokens, with a granularity that the requester can 
control (see the different modes in Section 5.1, Section 5.2 and 
Appendix B).

I think that a kind of similarity with the OCSP model can rather be seen 
in the optional introspection interaction, as optionally provided by the 
Authorization Server. There the requester actually provides a Token to 
be validated. Note that, while potentially applicable also for a Client, 
introspection in ACE is intended for the Resource Server.
<==

>
>> For a Client to
>>     access the Resource Server, the Client must present the issued Access
>>    Token at the Resource Server, which then validates and stores it.
> I guess the "stores it" seems surprising to me.

==>MT
This is simply referring to the main original workflow of the ACE 
framework, as background information. From Section 5.10.1.1 "Verifying 
an Access Token" [1]:

"When an RS receives an access token, it MUST verify it before storing it."


That is, a Token is stored at the RS (as well as at the Client it was 
issued to), until the Token expires or the entity owning it "somehow" 
learns it got revoked. This documents proposes a way to learn about 
that, through the TRL interaction and observe-based subscription.

[1] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-37
<==

> I think that it might be worth clarifying that it's the RS that would be
> subscribed to the TRL on the AS.

==>MT
Right, we can more explicitly mention the registration to be a subscription.

Note that the same applies to the Client just as well, for what concerns 
its pertaining Tokens it has obtained from the Authorization Server.
<==

> I think that the Intro should discuss
> Client vs RS code, and if there is a goal to require code changes at both
> ends or not.

==>MT
Good point; the abstract and introduction already say that this method 
does not require new ACE endpoints on Client and Resource Server, which 
would certainly be a notable addition.

As to additional required code, I can only think of:

- The actual request/response interaction with the AS to retrieve 
portions of the TRL; the real delta here should be limited to including 
the query parameters of the diff-query mode in Section 5.2 and to the 
parsing of the response payload.

- The local computing of Token hashes from the stored Tokens, to be 
compared against the responses from the Authorization Server.

Note that, once aware of a Token being revoked, a Client or Resource 
Server simply  proceeds as in the case of an expired Token. That is, it 
runs already available operations to delete the Token and purge 
associated security association as well as keying material.
<==

>
> Your protocol looks (at a quick scan) is very well worked out, but I don't
> know enough about when this would be used to understand what tradeoff you have made.

==>MT
Thanks, I think tradeoffs here boil down to the requester being able to 
request information on revoked pertaining Tokens with a granularity and 
level of detail under its control.

This can be expressed especially with the query parameters of the 
diff-query mode (see Section 5.2), and with further expressiveness in 
the enhanced diff-query mode based on the Series Transfer Pattern (see 
Appendix B). The latter additionally allows the Authorization Server to 
split the information to return into different transfers.

As highlighted in the examples in Section 8, a requester can also rely 
on a mix of Observe and non-Observe interactions with the Authorization 
Server, thus having a mix of actual subscriptions (e.g. in full-query 
mode) and polling (e.g. in diff-query mode).

One additional degree of control for the requester can be the usage of  
"pmax" conditional control attribute defined in the CoRE Dynlink 
document [2].


[2] https://tools.ietf.org/html/draft-ietf-core-dynlink-13



Thanks a lot again for your comments!

Best,
/Marco
<==

>
>
> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>             Sandelman Software Works Inc, Ottawa and Worldwide

-- 
Marco Tiloca
Ph.D., Senior Researcher

RISE Research Institutes of Sweden
Division ICT
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)

Phone: [phone]
https://www.ri.se