FYI, I haven’t seen any discussion on my review comment that these values
should be registered as CWT claims if continued alignment of values is desired.
Certainly the draft hasn’t done that. Do people see this alignment as
valuable?
What values to request for application-specific claims is a related, but
different issue. I could live with using some of the 2-byte space – possibly
requesting allocations from 255 down for those that are expected to be commonly
used and having the uncommon values be in the 3-byte space. But the 1-byte
space covering the range 0-31 should be reserved for claims that are of truly
broad applicability. Can the draft change the requested assignments for
application-specific values to at least move them out of the single-byte 0-31
range?
Thanks,
-- Mike
From: Jim Schaad <[email protected]>
Sent: Thursday, May 10, 2018 11:59 AM
To: Mike Jones <[email protected]>; 'Ludwig Seitz'
<[email protected]>; [email protected]
Subject: RE: [Ace] OAuth-Authz Interop
Given that we have already started doing interop work and were successful
needing to address the number assignment issues does not seem to be a blocking
problem. As long as all of the people doing the interop testing are agreed on
what numbers should be there do not seem to be any issues in testing. The only
problem would be if there was a decision to ship products before the
assignments were finalized.
In terms of what size of items to use, this is going to be an interesting
argument and one that needs to be finalized at some point. However, it would
be just as easy to remove the sentence as to change the values so there are
multiple ways of solving this issue. I don’t know that I agree that
application-specific claim keys should be pushed all of the way up to 256,
there is always going to be a trade off at this point in terms of what size of
key to use vs how often it is believed that the key is going to be used. If we
believe that a huge percentage of usage in the IoT world for CWT items is going
to be for this type of authorization and we want to keep alignment to the
extent possible then it still makes sense to use the 1 or 2 byte keys for this
purpose. (Side node, it is normal to include all of the bytes encoded in the
length so 256 would be a 3 byte value). This is a trade off that needs to be
discussed, but is not currently blocking.
Jim
From: Ace <[email protected]<mailto:[email protected]>> On Behalf Of Mike
Jones
Sent: Tuesday, May 8, 2018 10:40 AM
To: Ludwig Seitz <[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
Subject: Re: [Ace] OAuth-Authz Interop
Before any interop work is done, I suggest that it would be better to first
address the significant CBOR number assignment issues I pointed out in my
review on October 10, 2017
https://www.ietf.org/mail-archive/web/ace/current/msg02364.html, so that the
interop is more likely to occur using number assignments that are less likely
to change. I'm repeating the most important of these comments below, since it
was apparently not acted upon.
5.5.5 Mapping parameters to CBOR
It looks to me like these values are intended to align with those registered in
the CBOR Web Token (CWT) Claims registry initially populated by
https://tools.ietf.org/html/draft-ietf-ace-cbor-web-token-08#section-9.1.2. If
so, the spec should make this relationship explicit. However, it would be
inappropriate to use the rare single-byte CBOR integer values for
application-specific claim keys. I would suggest that the claim identifiers
for client_id through refresh_token and profile start at 256 (a two-byte CBOR
value) and go up from there. In that case, I suspect they could be
successfully registered in the CWT Claims registry – which I think you want.
(“cnf” will already be registered by draft-ietf-ace-cwt-proof-of-possession.)
Likewise, please search the review for all instances of the words “register”
and “registry” and revised the spec accordingly before any interop work is
started.
-- Mike
-----Original Message-----
From: Ace <[email protected]<mailto:[email protected]>> On Behalf Of
Ludwig Seitz
Sent: Tuesday, May 8, 2018 3:54 AM
To: [email protected]<mailto:[email protected]>
Subject: Re: [Ace] OAuth-Authz Interop
On 2018-05-08 08:57, Ludwig Seitz wrote:
> On 2018-05-07 18:44, Jim Schaad wrote:
>> I have been meaning to get this out for a while and have failed. A
>> doodle poll to setup an interop event for this work is at
>> https://doodle.com/poll/k27g9r26bghvnytu If you want to participate
>> and none of the times are good please let me know.
>>
>> Things for testing:
>> 1) DTLS profile w/ shared secret
>> 2) DTLS profile w/ RPK
>> 3) OSCORE profile
>>
>>
>
> Note that I'm in the process of writing a test manual, I'll put it up
> on the WG github as soon as it has some form and structure. Feel free
> to contribute. I'm hoping to have it online by the end of the day.
>
> /Ludwig
>
>
You can find my first draft of the interop manual here:
https://github.com/ace-wg/ace-oauth/blob/master/InteropTestPlan.txt
Note that large parts are still work in progress, but the test plan for the
token endpoint should give you a hint as to how I was thinking it could work.
Feel free to propose changes and improvements.
/Ludwig
--
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51
_______________________________________________
Ace mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/ace
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
