ACE Virtual Interim Meeting - 2nd March 2016 ============================================ Meeting minute taker: Kepeng Participants: - Erik - Francesca - Jim - Klaus - Ludwig - Mohit - Olaf - Samuel - Stefanie - Hannes - Kepeng - Carsten - Goeran - Robert - Sandeep - Michael - 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 https://www.ietf.org/proceedings/interim/2016/03/02/ace/slides/slides-interim-2016-ace-1-3.pdf 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) https://www.ietf.org/proceedings/interim/2016/03/02/ace/slides/slides-interim-2016-ace-1-1.pdf 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) https://www.ietf.org/proceedings/interim/2016/03/02/ace/slides/slides-interim-2016-ace-1-5.pdf 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) https://www.ietf.org/proceedings/interim/2016/03/02/ace/slides/slides-interim-2016-ace-1-0.pdf 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) https://www.ietf.org/proceedings/interim/2016/03/02/ace/slides/slides-interim-2016-ace-1-2.pdf 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 PSK-based credential. 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) https://www.ietf.org/proceedings/interim/2016/03/02/ace/slides/slides-interim-2016-ace-1-6.pdf 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? Erik: No. 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.