Hello ACE,
I wanted to post a resume of the in room discussions from the IETF 103
meeting, related to draft-ietf-ace-oauth-authz, for those who missed
them and those who want to further comment (sorry for the verbose
summary below):
During my presentation I put up a 7 issues for discussion as follows:
1. Use of one-byte CBOR abbreviations for parameters and CWT claims.
So far there is a consensus between me and Mike Jones on what we think
is reasonable.
This would be summarized here:
https://www.ietf.org/mail-archive/web/ace/current/msg03053.html
I was wondering if anyone else wants to weight in on what they consider
important parameters & claims for constrained applications that need
compact (one-byte) abbreviations in CBOR?
2. Unified registry for CWT claims and token/introspection parameter
abbreviations
Currently the draft(s) have aligned the CBOR abbreviations for both CWT
claims and token/introspection parameters under one singe number space.
There were arguments for splitting this up so that we can re-use the
same compact one-byte abbreviations in those different "namespaces" i.e.
there would be a number range just for CWT claims, and a separate one
for introspection and token endpoint parameters.
Even here I'm interested in additional input.
3. CWT as format for signed protocol messages
As OAuth is currently working on a number of drafts specifying JWT as a
format for encoding request (and response?) parameters wrt. the token
and the introspection endpoint, the question was raised whether this
should also be done for ACE and CWT.
My stance here (and I got the impression that the room agreed or at
least had no strong opinion against) is that this is absolutely
possible, but would best be done in an additional draft in order to not
increase the already significant delay of draft-ietf-ace-oauth-authz.
4. Alignment between "req_aud" and "resource" parameters
draft-ietf-oauth-resource-indicators proposes a new parameter for the
token request called "resource" which specifies the location of the
resource or service for which the token is requested. This is supposed
to map to the audience claim in the token.
draft-ietf-ace-oauth-params has in parallel defined the "req_aud"
parameter (for "requested audience") which has a somewhat broader
definition, roughly speaking "a value that the RS identifies with". This
could be a public key, a group identifier or something else, so the key
difference is that it is not specifically bound to the location of the RS.
I would argue to keep the "req_aud" as it is currently (since it covers
a broader set of use cases than "resource"), but I would be curious to
hear additional arguments for or against.
5. Handling of multiple tokens for one pair of client-RS
The question was whether an additional token issued for the same
client-RS pair would
a.) Amend the permissions (i.e. scope) of the older token(s)
b.) Replace all older tokens for that client-RS pair
My implementation and my current understanding of the draft was a.) but
apparently OAuth mostly does b.).
I would be strongly in favor of doing b.) (and clarifying the specs to
this end) since it greatly simplifies the code on the RS side. Unless
someone has a strong argument for approach a. I will implement that
change in the next document update.
6. Do we need the expiration mechanism based on sequence numbers?
Section 5.8.3 of the draft currently proposes a sequence-number-based
mechanism for expiration of access tokens on devices that do not have an
internal clock. Since this mechanisms has pretty severe limitations and
thus very weak security properties, and since we haven't yet seen a use
case involving devices without at least an internal "wall-clock time" I
propose to remove that mechanism from the draft, which seemed to be the
in-room consensus as well.
7. Symmetric proof-of-possession keys and multi RS audiences
Currently the draft does NOT RECOMMEND this, since it allows one RS to
impersonate the client towards other RSs that are part of the audience.
The in-room consensus seemed to be that this should be a MUST NOT
instead and I agree.
/Ludwig
--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
