Marco Tiloca <[email protected]> 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}
> 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.
I think that it might be worth clarifying that it's the RS that would be
subscribed to the TRL on the AS. 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.
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.
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
