Subject: [Ace] Meeting Minutes (Virtual Interim Meeting -- 30/09/2015)

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 1 Oct 2015 19:17:08 +0200

Please take a look at the meeting minutes from our virtual interim meeting:
https://www.ietf.org/proceedings/interim/2015/09/30/ace/minutes/minutes-interim-2015-ace-1

Let us know if you have comments.

Ciao
Hannes

---------

Authorization for Constrained Environments (ACE) WG Virtual Interim Meeting
---------------------------------------------------------------------------

Date: 30/09/2015
Chairs: Kepeng Li/Hannes Tschofenig

Participants:
 * SeanTurner
 * Kepeng Li
 * Klaus Hartke
 * Kathleen Moriarty
 * Goeran Selander
 * Abhinav Somaraju
 * Erik Wahlstroem
 * Michael Richardson
 * Olaf Bergmann
 * Mohit Sethi
 * Paul Madsen
 * Samuel Erdtman
 * Sandeep Kumar
 * Friedhelm Rodermund
 * Hannes Tschofenig
 * Jim Schaad
 * Ludwig Seitz
 * Carsten Bormann
 * Corinna Schmitt
 * Daniel Lindau
 * Malisa Vucinic
 * Vinod Choyi
 * Steffi Gerdes
 * Jorge Cuellar
 * Prashant Jhingran

Kepeng opened the meeting and pointed the participants to the note well,
which can be found at: https://www.ietf.org/about/note-well.html

He bashed the agenda and nobody requested changes.

1) Rechartering

Kepeng showed the updated charter text to the group and asked for comments.
No new comments on the charter text.

The new charter will be sent to the IESG for approval.

2) Use Cases

Ludwig reported about the status and the open issues Kathleen raised.
Hannes was asked to provide feedback this week about the privacy
consideration section.

Kathleen asked to submit a new version this week due to the timing with
the IESG conference call.

Sean mentioned that he has some comments and will post them to the list.

3) Architecture

Carsten reported about the status and the email he posted to the mailing
list. Here is the mail:
http://www.ietf.org/mail-archive/web/ace/current/msg01360.html

The term 'non-repudiation' was replaced with 'third party verifiability'.

Discussion about intermediaries was started and two types of
intermediaries have been identified:
 (a) transparent forwarders, and
 (b) actors that process the messages and participate in the security
processing.

Goeran mentioned other sub-categories where intermediaries may be able
to read messages but are not able to modify them. Yet other
intermediaries are able to verify signatures but cannot read the content
of the messages.

Jim also had comments regarding intermittent connectivity and Carsten
asked the group to provide better input.

Jim also noted that availability is a security goal.

The term 'security domain' seems to be used in various places in the
document but with different and un-defined meaning.

Currently the review comments are pretty much based only based on a
single review from Jim. We need more reviews.

Kepeng raised the topic of terminology. Goeran explained why he believes
little reason to move away from OAuth terminology.

Kathleen explained the process and the agreement reached on terminology
in the Dallas IETF meeting, which was followed by the document authors.

Ludwig noted that we will have a world where IoT devices are combined
with non-IoT devices. Hence, new terminology does not help to
communicate the ideas.

Steffi disagreed with him and argues that there is confusion.

Ludwig asked whether an OAuth authorization server is very different
from an authorization manager.

Steffi thinks that there are differences.

Carsten agrees with Steffi.

Goeran believes that some of these terminology discussions are solution
dependent. You can also use the 'ACE-' prefix to avoid confusion.

Goeran noted that the term 'CAS' was invented by Carsten.

Samuel said that he read the use case document and he is familiar with
OAuth. He did not need additional terminology; the use cases read nicely
without new terminology.

Carsten noted that there is at least a solution specific aspect in here.

Goeran asked Carsten what use cases cannot be accomplished with OAuth
terminology.

Carsten said that every solution solves every use case.

Goeran asked Carsten to post a mail to the list to explain what cannot
be described with OAuth terminology.

Paul mentioned that there is an Authorization Manager (AM) in UMA. It
manages entities from other security domains.

Kepeng asked Carsten to make a proposal to the list.

Kepeng suggested to talk about tasks next.

Carsten suggested to have WG participants to look at Steffi's task
document and whether this is something useful to address Jim's comments.

Goeran looked at the document and posted comments to the list. We don't
need to reference the draft for various reasons. Many parts are
overlapping and other parts are not needed. ACE has already stretched
the limit on informational documents.

Carsten we should definitely not ask for working group time since it is
a bit too complicated. It still provides information to those reading
the actors document and need further background.

Kepeng: we definitely don't have enough resources in the group to work
on that document.

Ludwig posted a mail to the list with the summary.

Nobody seems to remember the document and it got lost. Ludwig will post
the info again to the list.

Goeran believes that it should not be too difficult to resolve the
comments from Jim. It should not need 20 pages.

Ludwig took the headlines and it was pretty obvious without the text.

Carsten: We should take the issues to the list.

Kepeng: New text needs to be provided to resolve the comment raised by Jim.

Kepeng: Next topic -- Categories of intermediaries

Hannes explained the types of intermediaries (discussed a previously)
and Goeran believes that those are the different types.

Goeran will send a mail to the list listing the different proposals.

Kepeng: Structure of Section 2.

Carsten believes it is not worth trying to fix this.

Jim: It is OK not to address my comments. I found the flow unhelpful but
other people may not have that problem.

Kepeng: Diagrams -- confusion about information flow

Jim has not had a chance to review the new document yet.

Olaf was asked about his comment regarding Figure 7 about "Information
flows that need to be protected". It appears to be confusing.

Ludwig thinks it is confusing because there are two aspects shows in the
figure, namely the information flows and the fact that an endpoint can
act as a client and as a resource server.

Carsten will look into the term security domain and figure out what is
meant in each occurrence.

Reviewers: Sean Turner, Sandeep Kumar, and Samuel agreed to do reviews.