Subject: [Ace] OAuth-Authz Interop

From: Jim Schaad <[email-masked]>
Date: Mon, 7 May 2018 09:44:34 -0700

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

---

From: Ludwig Seitz <[email-masked]>
Date: Tue, 8 May 2018 08:57:12 +0200

> 1)  DTLS profile w/ shared secret

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

-- 
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51

---

From: Ludwig Seitz <[email-masked]>
Date: Tue, 8 May 2018 12:53:37 +0200

> contribute. I'm hoping to have it online by the end of the day.

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

---

From: Mike Jones <[email-masked]>
Date: Tue, 8 May 2018 17:40:19 +0000

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-masked]> On Behalf Of Ludwig Seitz
Sent: Tuesday, May 8, 2018 3:54 AM
To: [email-masked]
Subject: Re: [Ace] OAuth-Authz Interop

>> 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.

> 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.

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.

/Ludwig

--

Ludwig Seitz, PhD

Security Lab, RISE SICS

Phone +46(0)70-349 92 51

_______________________________________________

Ace mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/ace

---

From: Ludwig Seitz <[email-masked]>
Date: Wed, 9 May 2018 09:38:53 +0200

On 2018-05-08 19:40, Mike Jones wrote:
> 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.

I was pretty sure we went over all of your comments and replied to
you on list. We might have disagreed on some, but in that case we
clearly stated that.

Would you please specify which of your comments we have not acted upon,
so that we can rectify that?

Also I don't think the mapping of a few abbreviations should stop us 
from performing an interop.

Detailed comments below.

/Ludwig

> 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.

We did address this comment.

See:
https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-11#section-5.6.5
https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-11#section-5.7.4

"   Note that we have aligned these abbreviations with the claim
    abbreviations defined in [I-D.ietf-ace-cbor-web-token]."

We will update that reference to the RFC in the next iteration.

> 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.)
> 

Those claims/request parameters are from the core OAuth 2.0 spec. I can
buy an argument that they are not relevant for constrained applications,
but they are by no means application-specific. Shall we make a case-by
case evaluation of these?

The ones used in the draft are:

aud, scope, error, error_description, error_uri, grant_type,
access_token, cnf, profile, rs_cnf.

For the Authorization Code Grant (which has been pointed out as
relevant) I would think we also need:

response_type, client_id, state, code

I would be ok with pushing the other parameters/claim keys into the
two-byte abbreviation space.

> 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.

I'm pretty sure we did cover all of your comments. Here is what we did 
(a long while ago), just for your reference:

> 5.6.5 Mapping Introspection Parameters to CBOR
> 
> As in my related comment on 5.5.5, 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.)
> 

Done, see above

> 8.1 OAuth Introspection Response Parameter Registration
> 
> Every place an IANA registration currently says “this document”, 
> please change it to “Section x.y.z of this document” (using the 
> appropriate <ref target=”x.y.z”/> tag for the section that defines 
> the value.
> 
> 
We followed the example of other documents that also lacked the specific
section references. If you think this is important we can make that change.

> 
> 8.1 OAuth Introspection Response Parameter Registration
> 
> “aud” is already registered at 
> https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#token-introspection-response.

In this draft aud is also used in the authorization token request. The
registry entry you point at is from the OAuth Token Introspection
Response list we want to have that parameter in the OAuth Parameters
list as well.

> 
> 8.4 Token Type Mappings
> 
> The name “Token Type Mappings” registry is too generic.  Please 
> change it to “OAuth Token Type CBOR Mappings” or something similar.
Done, this is now 8.5

> 8.4.1  Registration Template
> 
> As was pointed out in comments on earlier versions of the CWT spec, 
> the range 1 to 65536 makes no sense.  Please consider using the same
>  treatment of value ranges as CWT does (which themselves derived from
>  the COSE usage of value ranges).  Do this consistently every place 
> that “1 to 65536” occurs in the spec.
This seems to have been missed. I will go over that again.

> 8.5 CBOR Web Token Claims
> 
> “cnf” is already being registered by
> draft-ietf-ace-cwt-proof-of-possession.
> 
It is being registered as a authorization token claim. We are
registering it in the OAuth Parameters and OAuth Token Introspection
Response.

> 8.6 ACE Profile Registry
> 
> The name “ACE Profile Registry” registry is too generic.  Please
> change it to “ACE OAuth Profile Registry” or something similar.
> 
Done

> 8.7 OAuth Parameter Mappings Registry
> 
> The name “OAuth Parameter Mappings” registry is too generic.  Please
> change it to “OAuth CBOR Parameter Mappings” or something similar.
Done

> 8.7.2 Initial Registry Contents
> 
> Per my earlier comments, these values should actually reference the
> CWT Claims registry and application-specific values such as
> “client_id”, etc. should not use the scarce single-byte value range.
See discussion above

> 8.8.1 Registration Template
> 
> Registrations for the Introspection Endpoint CBOR Mappings registry
> should contain a field that lists the corresponding value registered
> in the OAuth Token Introspection Response registry at
> https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#token-introspection-response.
That would be the "Name" field. It currently refers to the OAuth 
Parameters registry, would you prefer that we refer to the specific 
section "OAuth Token Introspection Response"?

> 
> 8.10 CWT Confirmation Methods Registry
> 
> Delete this section, as it has been moved to
> draft-ietf-ace-cwt-proof-of-possession.
> 
Done

-- 
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51

---

From: Jim Schaad <[email-masked]>
Date: Thu, 10 May 2018 11:59:18 -0700

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-masked]> On Behalf Of Mike Jones
Sent: Tuesday, May 8, 2018 10:40 AM
To: Ludwig Seitz <[email-masked]>; [email-masked]
Subject: Re: [Ace] OAuth-Authz Interop

                                                                -- Mike

-----Original Message-----
From: Ace <[email-masked] <mailto:[email-masked]> > On Behalf Of Ludwig Seitz
Sent: Tuesday, May 8, 2018 3:54 AM
To: [email-masked] <mailto:[email-masked]> 
Subject: Re: [Ace] OAuth-Authz Interop

>>  <https://doodle.com/poll/k27g9r26bghvnytu> https://doodle.com/poll/k27g9r26bghvnytu If you want to participate 

 <https://github.com/ace-wg/ace-oauth/blob/master/InteropTestPlan.txt> https://github.com/ace-wg/ace-oauth/blob/master/InteropTestPlan.txt

 

/Ludwig

--

Ludwig Seitz, PhD

Security Lab, RISE SICS

Phone +46(0)70-349 92 51

Ace mailing list

 <mailto:[email-masked]> [email-masked]

 <https://www.ietf.org/mailman/listinfo/ace> https://www.ietf.org/mailman/listinfo/ace

---

From: Mike Jones <[email-masked]>
Date: Thu, 10 May 2018 20:00:15 +0000

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-masked]>
Sent: Thursday, May 10, 2018 11:59 AM
To: Mike Jones <[email-masked]>; 'Ludwig Seitz' <[email-masked]>; [email-masked]
Subject: RE: [Ace] OAuth-Authz Interop

Jim

From: Ace <[email-masked]<mailto:[email-masked]>> On Behalf Of Mike Jones
Sent: Tuesday, May 8, 2018 10:40 AM
To: Ludwig Seitz <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Ace] OAuth-Authz Interop

                                                                -- Mike

-----Original Message-----
From: Ace <[email-masked]<mailto:[email-masked]>> On Behalf Of Ludwig Seitz
Sent: Tuesday, May 8, 2018 3:54 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Ace] OAuth-Authz Interop

/Ludwig

--

Ludwig Seitz, PhD

Security Lab, RISE SICS

Phone +46(0)70-349 92 51

Ace mailing list

---

From: Ludwig Seitz <[email-masked]>
Date: Fri, 11 May 2018 15:06:15 +0200

On 2018-05-10 22:00, Mike Jones wrote:
> 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?*
> 

Everything that is used as CWT claim is also registered as such, if it 
is not already registered. In our case that is just the "scope" claim 
(we will be adding a "profile" claim in the next iteration).

However there are also OAuth token endpoint parameters and OAuth 
introspection parameters, that partially have the same names as CWT 
claims (and the same meaning). Those are registered in other respective 
registries.

I have aligned the CBOR abbreviations for both claims and parameters of 
the same name (we obviously don't want an "aud" parameter in the access 
token request that abbreviates to 4 and an "aud" claim in a CWT that 
abbreviates to 5).

Do you see any concrete mismatch in the current registrations? The IANA 
section has grown pretty large and an error might have slipped past our 
vigilance.

/Ludwig

-- 
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51

---

From: Ludwig Seitz <[email-masked]>
Date: Tue, 15 May 2018 15:46:52 +0200

> 1)  DTLS profile w/ shared secret

The dates Jim has proposed in the doodle are quite close already, and 
the poll is still quite empty. Is there any specific reason why the 
other implementers won't/cannot commit to this at this point in time?

/Ludwig

-- 
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51

---

From: Jim Schaad <[email-masked]>
Date: Fri, 18 May 2018 10:59:33 -0700

We are going to go with

May 30  07:00 PDT  (14:00 UTC) 

If there is anyone who has an IPv6 only client, please let me know as I will
need to get tunneling setup for my server.  (An IPv6 only server is not a
problem.)

Ludwig, we made some changes to the document at the last F2F meeting.  It
would be nice to get those changes published.

Jim

> Sent: Tuesday, May 15, 2018 6:47 AM
> To: [email-masked]
> The dates Jim has proposed in the doodle are quite close already, and the
> poll is still quite empty. Is there any specific reason why the other
> implementers won't/cannot commit to this at this point in time?
> 
> /Ludwig
> 
> --
> Ludwig Seitz, PhD
> Security Lab, RISE SICS
> Phone +46(0)70-349 92 51
> 
> [email-masked]

---

From: Ludwig Seitz <[email-masked]>
Date: Mon, 21 May 2018 11:35:18 +0200

> would be nice to get those changes published.

Done!

Please find draft -12 here:
https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/

/Ludwig

-- 
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51

---

From: Ludwig Seitz <[email-masked]>
Date: Mon, 28 May 2018 09:42:35 +0200

Hello virtual interop participants,

I think I have now come to a version of the interop test plan
(https://github.com/ace-wg/ace-oauth/blob/master/InteropTestPlan.txt)
that implements (most) of Jim's comments and feel relatively usable for 
the virtual interop.

The biggest change is that I reordered the tests so that you only need 
to run one server at a time for a batch of tests.

Sorry for the late changes, I hope we can test something on Wednesday.

/Ludwig

-- 
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone +46(0)70-349 92 51