Subject: [Ace] Solution direction

From: "Kepeng Li" <[email-masked]>
Date: Mon, 02 Nov 2015 13:39:21 +0800

At the face-to-face meeting of the ACE working group in Yokohama, the
participants in the room decided to accept the OAuth profiling draft as a
starting point for future work of the solution charter item:
http://datatracker.ietf.org/doc/draft-seitz-ace-oauth-authz/

For those who weren't present in the room, please let us know whether you
accept or object to this decision, before 17th Nov, 2015.

Thanks,

Kind Regards
Kepeng

---

From: Shahid Raza <[email-masked]>
Date: Mon, 2 Nov 2015 10:11:43 +0100

I accept this decision.

/Shahid

> On 02 Nov 2015, at 06:39, Kepeng Li <[email-masked]> wrote:
> 
> At the face-to-face meeting of the ACE working group in Yokohama, the participants in the room decided to accept the OAuth profiling draft as a starting point for future work of the solution charter item:
> http://datatracker.ietf.org/doc/draft-seitz-ace-oauth-authz/ <http://datatracker.ietf.org/doc/draft-seitz-ace-oauth-authz/> 
> 
> For those who weren't present in the room, please let us know whether you accept or object to this decision, before 17th Nov, 2015.
> 
> Thanks,
> 
> Kind Regards
> Kepeng 
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace

---

From: Paul Madsen <[email-masked]>
Date: Mon, 2 Nov 2015 07:29:34 -0500

accept

On 11/2/15 12:39 AM, Kepeng Li wrote:
> participants in the room decided to accept the OAuth profiling draft 
> as a starting point for future work of the solution charter item:
> For those who weren't present in the room, please let us know whether 
> you accept or object to this decision, before 17th Nov, 2015.
>
> Thanks,
>
> Kind Regards
> Kepeng
>
>

---

From: Stephen Moore <[email-masked]>
Date: Mon, 2 Nov 2015 08:40:05 -0500

Accept

-steve

---

From: Somaraju Abhinav <[email-masked]>
Date: Tue, 3 Nov 2015 03:07:45 +0000

Accept.
-Abhinav

________________________________
From: Ace [[email-masked]] on behalf of Kepeng Li [[email-masked]]
Sent: Monday, November 02, 2015 6:39 AM
To: [email-masked]
Cc: Kathleen Moriarty; Hannes Tschofenig; Stephen Farrell
Subject: [Ace] Solution direction

Thanks,

Kind Regards
Kepeng
________________________________________________________ The contents of this e-mail and any attachments are confidential to the intended recipient. They may not be disclosed to or used by or copied in any way by anyone other than the intended recipient. If this e-mail is received in error, please immediately notify the sender and delete the e-mail and attached documents. Please note that neither the sender nor the sender's company accept any responsibility for viruses and it is your responsibility to scan or otherwise check this e-mail and any attachments.

---

From: Samuel Erdtman <[email-masked]>
Date: Fri, 6 Nov 2015 18:20:20 +0100

Accept!

Best Regards
//Samuel Erdtman

---

From: Stefanie Gerdes <[email-masked]>
Date: Tue, 17 Nov 2015 10:07:29 +0100

Hi all,

I think we should continue working on DCAF in ACE. It provides valuable
concepts and mechanisms which is why many solutions in ACE draw heavily
from DCAF.

I think one aspect did not really become clear during the ACE session in
Yokohama: A solution with only one supporting less constrained device
will not be able to fully support communication between constrained
nodes as DCAF does. One main question that is only partly solved by
other solutions is: How can a constrained client authenticate the other
party?

A constrained device is not able to establish security associations as
easily as a less constrained device. The keying material that is used
for authorization and secure communication must securely be obtained. It
can either be provisioned manually to the constrained device or a
security association with a less constrained device is required that can
then provide the keying material.

An Authorization Server can provide session keys to the constrained
devices, but the constrained device must have a security association
with the AS to authenticate the origin of the session key. In a scenario
where we have only a single AS and two constrained nodes, both need a
security association with that AS. For cross-domain scenarios this might
be difficult. We will need to manually provision the keying material to
one of the devices which makes the dynamic setup of secure communication
impossible. That's why we need two less-constrained devices in this
scenario.

You may think that this has nothing to do with authorization and
therefore is not a topic for ACE. Well, it has, but another
terminology-discussion might not be that useful. However, the important
thing is that developing an additional solution to solve this problem
will very likely add more overhead. The result will be more complex and
more difficult to implement. Until such a solution is developed we will
need to use complex workarounds (e.g. manual provisioning), may have
security problems or are not able to address certain scenarios at all.

But we have never done this before, why now? Because other than the
general purpose computers that we are using today, constrained devices
will communicate autonomously without the help of their user. They often
will not even have user interfaces. Until now this was true for servers
which is why existing protocols protect them. In a true Internet of
Things this will also be true for clients. We therefore need to
reconsider how clients can be protected and how their actions can be
controlled by their owners.

DCAF supports scenarios with a single less-constrained device (AS) as
well as scenarios where both the Client and the Server have their own.
It works with OAuth and may even transport OAuth tickets if that is
necessary. It has a built-in key distribution mechanism and therefore is
very efficient. The main fault of DCAF seems to be that we didn't call
it OAuth.

I think DCAF should be one of the building blocks (one of the tools in
our toolbox) that ACE is working on.

Best regards,
Steffi

---

From: Olaf Bergmann <[email-masked]>
Date: Wed, 18 Nov 2015 10:01:56 +0100

As Carsten already said, it is difficult to object the decision to
continue with the OAuth-based approach because that is clearly one
thing needed to do short-term (therefore, we have presented the OAuth
integration with our proposal during IETF-93 in Prague and asked for
help from OAuth experts). Now, it seems that this work starts and
needed specifications for using OAuth tokens in the constrained sphere
will be developed. This is a good thing, and I really do not care
whether a required field name is taken from the OAuth sphere or from
our DCAF proposal. In the end, they will just be numeric identifiers
in CBOR where you cannot really tell the difference. So, this part of
the discussion so far was about coloring the bikeshed.

Where I object is to drop the work on the cross-domain,
multi-stakeholder scenario as this is what enabled constrained devices
to be part of a global Internet of Things. Many of those who have been
convinced to go the OAuth way currently do not see the urge to work on
this as their current use cases do not need this or their business
model could be negatively affected by first movers jumping on that
train. Now, I am very sure that both will happen, either based on IETF
standards or in the wild. Therefore, I vote for continuing work on the
cross-domain, multi-stakeholder scenario based on existing proposals,
including DCAF, because it already contains a lot of text and message
format specifications that show how this can work. We still can argue
whether the bits in the DCAF have the correct color of the day, but we
should not drop the added value that DCAF has.

Grüße
Olaf

---

From: Renzo Navas <[email-masked]>
Date: Wed, 18 Nov 2015 11:14:41 +0100

Good Morning everybody,

I do agree that we have to start focusing one one solution only, and
OAuth seems to have more momentum than DCAF, I read both drafts and
OAuth is clear and easy to understand.
I do not oppose to have OAuth-profiling as a starting point.

However I do agree with Olaf, that there are still some core issues
that are not addressed with OAuth-based solution yet but yes with
DCAF,
Notably the CAS concept is not present on the OAuth solution yet, and
CAS is an integral part of the Actors ACE document, so we will
eventually arrive to the point that we have to take CAS in account,
and then we will be doing some work DCAF is already doing.
So as Olaf say I vote also for maintaining DCAF at least for the
cross-domain CAS-needed case, and why not start merging it with the
OAuth-based solution on the points that OAuth is missing.

Saludos!

Renzo

---

From: Erik Wahlström neXus <[email-masked]>
Date: Wed, 18 Nov 2015 10:57:37 +0000

Hi,

Dynamic client registration (RFC7591) and User-Managed Access (UMA) Profile of OAuth 2.0 (https://docs.kantarainitiative.org/uma/rec-uma-core.html) solves those scenarios.

To make them work with constrained clients and servers, both RFC7591 and UMA must to be profiled in the same way as the OAuth for IoT draft did for core oauth.

Both dynamic client registration and UMA where added later on after Oauth2 (RFC6749) was completed. I think that’s a sound model that we should follow. Get the core concepts down, then extend them when needed and when we do that we should re-use the concepts already there.

Having two different proposals, both DCAF and OAuth for IoT, running at the same time confuses implementors. I don’t think we want to do that.

/ Erik

On 17 Nov 2015, at 10:07, Stefanie Gerdes <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

Best regards,
Steffi

_______________________________________________
Ace mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ace

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 18 Nov 2015 17:39:23 +0000

Don’t or won’t we already have that confusion with COSE and JOSE (much like confusion with DCAF and OAUTH) ?

From: Ace [mailto:[email-masked]] On Behalf Of Erik Wahlström neXus
Sent: Wednesday, November 18, 2015 2:58 AM
To: Stefanie Gerdes <[email-masked]>
Cc: Hannes Tschofenig <[email-masked]>; Stephen Farrell <[email-masked]>; Kathleen Moriarty <[email-masked]>; Kepeng Li <[email-masked]>; [email-masked]
Subject: Re: [Ace] Solution direction

Hi,

Dynamic client registration (RFC7591) and User-Managed Access (UMA) Profile of OAuth 2.0 (https://docs.kantarainitiative.org/uma/rec-uma-core.html<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fdocs.kantarainitiative.org%2fuma%2frec-uma-core.html&data=01%7c01%7ctonynad%40microsoft.com%7c2e4a423528b84869171d08d2f0071896%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ALYnNx65C18sUYQB3LgXOc5s5teOHDYv0NzqmCsubAI%3d>) solves those scenarios.

/ Erik

Hi all,

Best regards,
Steffi

---

From: Erik Wahlström neXus <[email-masked]>
Date: Wed, 18 Nov 2015 18:13:32 +0000

Don't think so. If it's a JWT/JOSE or a CWT/COSE does not mean the world. It's just a token format (both will exist). A client don't really have to care what type of token it is. It's just a access token.

Then we have the framework on how access tokens are retrieved and sent to establish a context. That's another thing.

/ Erik

Sent from my iPhone

On 18 Nov 2015, at 18:39, Anthony Nadalin <[email-masked]<mailto:[email-masked]>> wrote:

Don't or won't we already have that confusion with COSE and JOSE (much like confusion with DCAF and OAUTH) ?

From: Ace [mailto:[email-masked]] On Behalf Of Erik Wahlström neXus
Sent: Wednesday, November 18, 2015 2:58 AM
To: Stefanie Gerdes <[email-masked]<mailto:[email-masked]>>
Cc: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>; Stephen Farrell <[email-masked]<mailto:[email-masked]>>; Kathleen Moriarty <[email-masked]<mailto:[email-masked]>>; Kepeng Li <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Ace] Solution direction

Hi,

Both dynamic client registration and UMA where added later on after Oauth2 (RFC6749) was completed. I think that's a sound model that we should follow. Get the core concepts down, then extend them when needed and when we do that we should re-use the concepts already there.

Having two different proposals, both DCAF and OAuth for IoT, running at the same time confuses implementors. I don't think we want to do that.

/ Erik

Hi all,

Best regards,
Steffi

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 18 Nov 2015 18:17:18 +0000

Its more than that as we have to deal with JSON and CBOR, so far OAUTH only deals with JSON in the various profiles/extensions

From: Erik Wahlström neXus [mailto:[email-masked]]
Sent: Wednesday, November 18, 2015 10:14 AM
To: Anthony Nadalin <[email-masked]>
Cc: Stefanie Gerdes <[email-masked]>; Hannes Tschofenig <[email-masked]>; Stephen Farrell <[email-masked]>; Kathleen Moriarty <[email-masked]>; Kepeng Li <[email-masked]>; [email-masked]
Subject: Re: [Ace] Solution direction

/ Erik

Sent from my iPhone

Hi,

/ Erik

Hi all,

Best regards,
Steffi

_______________________________________________
Ace mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ace<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2face&data=01%7c01%7ctonynad%40microsoft.com%7c7d0c39fa74cf424c073f08d2f043fc00%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=fUd%2fyWsFTYJgyL8ylrY%2bLjeEDGYXOuEB7ikV5vKJ0M0%3d>

---

From: Erik Wahlström neXus <[email-masked]>
Date: Wed, 18 Nov 2015 18:31:27 +0000

Yes. Json will still be a key format. And it will be heavenly used, especially for class 2 devices. In our tests we did see that JWT got us a very long way. Especially if we just have to send token once (according to the draft).

Then we have the super constrained class 1 devices. They need something more compact.

Sent from my iPhone

On 18 Nov 2015, at 19:17, Anthony Nadalin <[email-masked]<mailto:[email-masked]>> wrote:

From: Erik Wahlström neXus [mailto:[email-masked]]
Sent: Wednesday, November 18, 2015 10:14 AM
To: Anthony Nadalin <[email-masked]<mailto:[email-masked]>>
Cc: Stefanie Gerdes <[email-masked]<mailto:[email-masked]>>; Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>; Stephen Farrell <[email-masked]<mailto:[email-masked]>>; Kathleen Moriarty <[email-masked]<mailto:[email-masked]>>; Kepeng Li <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Ace] Solution direction

/ Erik

Sent from my iPhone

Hi,

/ Erik

Hi all,

Best regards,
Steffi

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 18 Nov 2015 18:57:42 +0000

Makes more sense to have a solution that uses Oauth and JSON/JOSE and a DCAF solution that uses CBOR/COSE instead of mixing all the combinations as that will be a nightmare

Sent: Wednesday, November 18, 2015 10:31 AM

Sent from my iPhone

/ Erik

Sent from my iPhone

Hi,

/ Erik

Hi all,

Best regards,
Steffi

---

From: Erik Wahlström neXus <[email-masked]>
Date: Wed, 18 Nov 2015 19:08:15 +0000

If the constrained world and the non-constrained world would exists in two different parallell worlds that would make sense. But it’s not. It’s a continuum where both big and small devices will talk to each other. I will have a phone that talks standard oauth2 flows to get a token from an authorization server and it’s later used against a constrained device using coap and vice versa.

I would be fine if we only could get by with a JWT, but I don’t think so. Please prove me wrong :)

/ Erik

On 18 Nov 2015, at 19:57, Anthony Nadalin <[email-masked]<mailto:[email-masked]>> wrote:

Sent from my iPhone

Cc: Stefanie Gerdes <[email-masked]<mailto:[email-masked]>>; Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>; Stephen Farrell <[email-masked]<mailto:[email-masked]>>; Kathleen Moriarty <[email-masked]<mailto:[email-masked]>>; Kepeng Li <[email-masked]<mailto:[email-masked]>>;[email-masked]<mailto:[email-masked]>

/ Erik

Sent from my iPhone

Hi,

/ Erik

Hi all,

Best regards,
Steffi

---

From: Göran Selander <[email-masked]>
Date: Thu, 19 Nov 2015 08:07:45 +0000

Hi Renzo, 

On 2015-11-18 11:14, "Renzo Navas" <[email-masked]> wrote:

>cross-domain CAS-needed case,

An overwhelming majority at the F2F meeting wanted one solution with the
OAuth profile draft as a starting point. Assuming this is confirmed by the
WG (pending the ruling by the ACE chairs) my interpretation of “starting
point" is that we try to build whatever components missing onto the OAuth
profile draft, not maintain two solutions. And in that respect any
proposed solution component is welcome and should be judged by its merits,
like for example your proposal for nonce-based authenticated key
establishment.

> and why not start merging it with the

I don’t think a merge is a good idea, at least not in the sense of the
actors draft which is a result of the different views represented by some
of the authors behind the OAuth profile draft and some of the authors
behind DCAF. The two latest reviews were not very positive.

Göran

---

From: Stefanie Gerdes <[email-masked]>
Date: Thu, 19 Nov 2015 11:03:59 +0100

Hi Erik,

Fortunately, DCAF works with constrained AND less-constrained devices,
so we will not have "parallel worlds" if we use it.

Steffi

-- 
Stefanie Gerdes			Tel: +49 421 218 63906
TZI Universität Bremen		E-Mail: [email-masked]
Bibliothekstr. 1, MZH 5150
28359 Bremen, Germany

---

From: Erik Wahlström neXus <[email-masked]>
Date: Thu, 19 Nov 2015 10:19:51 +0000

Hi Steffi,

Yes, I realise that DCAF can be profiled and used to non-constrained devices just as OAuth can be profiled for constrained devices. For me, it’s more of a question of where momentum is and taking that further to target the continuum of both non-constrained and constrained devices (i.e. take OAuth to constrained devices).

/ Erik

> On 19 Nov 2015, at 11:03, Stefanie Gerdes <[email-masked]> wrote:
> 
> Hi Erik,
>

---

From: Paul Madsen <[email-masked]>
Date: Thu, 19 Nov 2015 05:50:44 -0500

Enterprises know & understand OAuth and many have already invested in it 
to protect their HTTP APIs

A security model for constrained devices that builds on this established 
collective knowledge & experience with OAuth (and the other specs that 
have been defined on it like Connect & UMA) is a much easier proposition 
for these enterprises as they roll-out IoT

paul

---

From: Stefanie Gerdes <[email-masked]>
Date: Thu, 19 Nov 2015 13:55:19 +0100

Hi Erik,

DCAF as it is already supports less-constrained devices. It also works
together with OAuth as we showed in an example in
draft-gerdes-ace-dcaf-examples [1]. If we want to, we can also transport
OAuth tickets in DCAF. We should find out which is more useful for which
use case (we may find out that there is more than one answer to that).

The discussion always seems to be whether we are doing something for the
constrained devices or if we are supporting OAuth. I think we should do
both. I don't think it is that important whether we name the result
DCAF, OAuth or UMA in the end as long as it does the right thing.

Best regards,
Steffi

[1] https://tools.ietf.org/html/draft-gerdes-ace-dcaf-examples-00

---

From: Stefanie Gerdes <[email-masked]>
Date: Thu, 19 Nov 2015 14:03:41 +0100

Hi Göran,

> behind DCAF. The two latest reviews were not very positive.

I don't think we should be to pessimistic. The use cases document was
hard work but turned out to be especially useful in the end. I think
that is a remarkable success.

Best regards
Steffi

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 19 Nov 2015 08:36:45 -0500

Hi,

Sent from my iPhone

> On Nov 19, 2015, at 5:03 AM, Stefanie Gerdes <[email-masked]> wrote:
> 
> Hi Erik,
> 

Is DCAF deployed?  I believe UMA is, right?  If DCAF were used, we would have "parallel worlds".

Thanks,
Kathleen

---

From: Stefanie Gerdes <[email-masked]>
Date: Thu, 19 Nov 2015 14:43:33 +0100

Hi Kathleen,

> Is DCAF deployed?  I believe UMA is, right?  If DCAF were used, we would have "parallel worlds".

Only if DCAF and UMA contradict each other which I believe is not true.

Best regards,
Steffi