Skip to main content

Minutes for ACE at interim-2015-ace-1
minutes-interim-2015-ace-1-3

Meeting Minutes Authentication and Authorization for Constrained Environments (ace) WG
Date and time 2015-09-30 07:00
Title Minutes for ACE at interim-2015-ace-1
State Active
Other versions plain text
Last updated 2015-10-01

minutes-interim-2015-ace-1-3
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
 * Tony Nadalin

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.