Minutes for ACE at interim-2016-ace-1
Authentication and Authorization for Constrained Environments
||Minutes for ACE at interim-2016-ace-1
ACE Virtual Interim Meeting - 2nd March 2016
Meeting minute taker: Kepeng
- Dave Robin
0) Intro (Kepeng/Hannes)
Hannes showed the charter text and indicated that the group should think about
the indicated timelines. What are the expectations of the group about finishing
the ACE OAuth document? Do we want reference implementations (or
interoperability testing) before the sending the document to the IESG?
1) Architecture Draft (Carsten)
Carsten took the two reviews from by Abhinav Somaraju and Samuel Erdtman into
account and incorporated editorial suggestions. Carsten believes it is in
better shape and solicits further comments. 2 reviewers from last IETF
meeting are asked to look at the document. Encourages reviewers to specially
look at the document with respect of what could be deleted/omitted. Should
not delete sections that are obvious for the participants in the working
group. Kepeng: a big open item is about the entities. The actors draft has 4
entities while the ACE OAuth draft only has 3 entities. Carsten: That's an
important question. The actors draft provides a general model and not every
solution will fill in every components of the model. It is important to
capture the structure and over time we might do solutions that use the other
components as well.
Reviewers, who volunteered at the Yokohama, Sandeep, Robert, and Robin.
Michael also volunteered to do a review.
2) ACE OAuth
* Credential types
Goran: Use PoP methods for mutual authentication, which one is most relevant?
Samuel: Do we need certificates for both sides, client and server?
Michael: About credential type, we must cover the mandatory one (RawPublicKey),
and we should cover one or two “may implement” ones.
* Deployment Options (Goeran)
Goeran talks about the different deployment scenarios (such as,
offline/online). Should these profiles go into different drafts? Framework
supports all the deployment scenarios. Sandeep: don’t make the framework draft
too heavy. Can be separated in different profiles. Erik: move the deployment
options to the appendix. Sandeep: There are 6 profiles listed; are they
interoperable between each other? Michael: they are not intended to be
interoperable. Goran: all of 6 profiles are consistent with the framework.
Hannes: The different profiles are not meant to be interoperable among each
other. However, they are consistent with the framework. Michael: If I develop a
rich client would it be able to support multiple profiles and would it then be
interoperable with RSs supporting different profiles? Goeran: Yes.
* RS Synchronized Time (Goeran)
Goeran talks how to achieve synchronized time between Resource Server and
Authorization Server. Several options are listed in the slides. Carsten: Yes,
we need a solution that does not rely on clock synchronization for the RS.
Hannes points out that the solution for it has some drawbacks as well.
Discussion about what the requirements exactly are. There seems to be a
difference between time synchronization requirement and the requirement for a
real-time clock itself.
Hannes: This is one of the profiling issues. It sounds like a separate profile.
Hannes: Every solution has its downsides. Have to look at the details to see
how the solutions work and discuss them on the mailing list.
* CBOR and/or JSON(Samuel)
Discussion about whether CBOR and / or JSON should be described in the WG
document. Four options: - Alternative 1: CBOR and JSON and all components to
make CoAP work. - Alternative 2: CBOR only and extend later on with JSON. -
Alternative 3: JSON only and extend in parallell with CBOR. - Alternative 4:
CBOR and JSON and support for both CoAP and HTTP.
Carsten suggested another variant: Only do CBOR.
Ludwig: Don’t choose 1 or 4. Prefer 2.
Eric: OK with 2. Prefer 4.
Sandeep: Prefer 2.
Michael: Suggest to call for consensus on the mailing list.
* Token Transport (Ludwig)
Ludwig presented several options. All of them have advantages and disadvantages.
– POST to a well-known or discoverable resource (e.g. /authz-info)
– Use a dedicated CoAP option
– Use TLS supplemental data (RFC 4680)
– Use psk_identity (DCAF)
- Define new TLS certificate type (similar to RPK)
No obvious candidate.
Carsten believes that the psk_identity approach is the best approach for a
Jim mentioned that another option is to use ticket extension (RFC 5077)
Hannes explains the approach a bit and suggests to look into it.
3) CWT (Erik)
Samuel: Should you reference the content from the JWT draft instead of
repeating the content? Erik: In version -00 we copied the text from the JWT
draft but with version -01 we are now referencing JWT.
Samuel: Are there any new attributes in the draft?
Hannes: Chairs will ask for adoption in the mailing list.
4) Next steps (Chair)
Hannes asked who will be at the upcoming IETF meeting.
Goeran, Carsten, Jim will attend the F2F meeting.
Ludwig, Klaus, Sandeep, Steffi will attend remotely.
Hannes & Kepeng are still discussing their participation.