Minutes for OAUTH at IETF-87
minutes-87-oauth-3

Web Authorization Protocol (OAuth)
==================================

Date: WEDNESDAY, July 31, 2013
Time: 0900-1130 CEST
Room: Tiergarten 1/2

Chairs: Hannes Tschofenig/Derek Atkins
Minute Taker: Leif Johansson

* Abbreviations:

 - Torsten Lodderstedt (TL)
 - Barry Leiba (BL)
 - Leif Johansson (LJ)
 - Tony Nadalin (TN)
 - Hannes Tschofenig (HT)
 - Derek Atkins (DA)
 - Phil Hunt (PH)
 - Paul Hoffman (PHO)
 - Mike Jones (MJ)
 - Lucy Lynch (LL)
 - Nat Sakimura (NS)
 - Carsten Bormann (CB)
 - John Bradley (JB)

* Chair Overview (DA & HT)

  - Milestone review.
  - BL notes that the old notewell was used
  - Use case draft needs a new document editor. Several persons volunteered to
  do a review including TN, Robin Wilton, JB, TL, and Peter Gietz. - Agenda
  Bashing

 * Dynamic Client Registration

   - Working group document (JB)
 https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/

    - LJ asked for clarification in sec considerations on none method and
    signed metadata - TN This document should not be in WGLC right now - too
    many open issues and alternative proposals - LJ - probably want to say
    "let's not progress beyond WGLC" - PH echo TN comments. Surprised that this
    went to WGLC - DA WGLC does not mean "no more changes" - PHO mismatch
    between what authors believes and what WG believes about the document
    readyness - HT & PHO discuss what to do about the draft. - PH: not clear
    what to do about the two competing proposals - PHO: not at all comfortable
    with multiple solutions. we should not be at WGLC at all.

   - SCIM-based Proposal (PH)
 https://datatracker.ietf.org/doc/draft-hunt-oauth-scim-client-reg/

    - JB - (about "Basic Flow" diagram) up to E it could be the dynamic reg
    spec, i.e the top part of the diagram isn't in conflict with the current
    proposal. There is a second proposal that is quite different and is not
    compat. with dynreg. - Justin (via jabber): nervous about parsing software
    version - PH: spec says only do direct compare, so no issue there - Robin
    Wilton: can the two specs be progress separately? - PH: it makes sense to
    keep using SCIM for provisioning but understand that OpenIDC folks need
    something can stand on its own - JB: several ideas need to be compared for
    doing something about application registration & provisioning. The dynreg
    spec leaves a hook for this. From OpenIDC pov low priority for taking on a
    dependency on SCIM. - PH: several of these issues need more discussion.
    push back on WGLC at this time for dynreg. - Justin (jabber): make sense
    for this to be separate draft sitting on top of SCIM base spec and dynreg -
    TN: we use SCIM as an endpoint for this. We believe that the static schema
    in dynreg is a misstake & big problem - Justin (jabber): Schema is plenty
    extensible - PH: ignoring unknown schema elements is not extensibility -
    PHO: resonable amount of disagreement - should we push forward at all? -
    HT: need to figure out what the other groups want - PHO & others talk about
    who "owns" Blue Button+ & what to do & what constitutes interop. - PHO & LJ
    - is there a common direction? - MJ disagree that this was developed for
    OpenIDC. Question for WG: do we want an interoperable solution for this? -
    PH: what is the critical point of interop? - MJ: fair enough - PH: primary
    concern has always been OpenIDC if you look at the mailthread. - MJ & JB:
    not true - we've (OpenIDC) has accepted breaking changes - TN: why are we
    really doing this instead of completing other efforts in OAUTH? - HT: the
    WG has stated that it wants this - Justin (jabber): dynreg isn't just
    OpenIDC - PH: move on to the second proposal... describes an alternative
    proposal - Justin (jabber): there isn't always a rel. with the API
    publisher - Multiple: discussion about the idea - several expressions of
    cautios interest - JB: unclear how this works for webserver apps -
    Discussion about scalability and the webapp case - PH: highlighting how
    OpenIDC is a special case - more discussion - TL: lets modularize - have
    separate I-D for software statements - PH: dynreg may be fine but maybe not
    the only solution - PH: need to think about how these specifications relate
    to each other - Justin (jabber): how does this handle one piece of sw
    talking to multiple ASes? - PH: need to consider carefully - LL: echo TL &
    pickup the "profile" meme. Write this up as profiles & architect carefully!
    - Justin (jabber): applauding! - HT: we will reach out to some of the
    implements (like Roland Hedberg or the BlueButton guys) - HT: will host
    design team calls - PH to split off software assertion into separate spec

 * JWT (MJ)
 https://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/

    - very few updates
    - time for WGLC? underlying JOSE specs are stable enough
    - HT: objections to WGLC? (none voiced)
    - TL, Karen, PHO, BC volunteered to do WGLC review

 * Assertions (BC)
 https://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/
 https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bearer/
 https://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/

    - WGLC ends by 8/8
    - BL on WGLC comments: talked to MJ about how to achieve interop.
    - BL: describe how you could combine specifications to make at least one
    interoperable specification - MJ: profiles exists for both SAML and
    OpenIDC. those are not IETF specifications though - BL: ok to point to
    external doc from either of the I-Ds in question - MJ: very achievable -
    BL: all should go to the IESG at the same time to establish context - PHO:
    is this for the IESG benefit or for future developers - BL: the latter -
    PHO: talk to Heather Flanagan or the IANA - they have talked about having
    long-term access to external documents - BL: ok will consider that - or we
    can copy text into WG wiki - BC: interop does not require external profiles
    actually - TL: same experience at DT with the JSON-based assertion format -
    no addl profiles are needed - MJ: a SAML deployment needs agreement on
    certain SAML-specific conventions - this is what BL is referring to - BC:
    right - TN: so just refer to the SAML specs - BL: maybe enough - JB and TL
    volunteered to make a review.

 * Security (HT)
 https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-http-mac/
 https://datatracker.ietf.org/doc/draft-tschofenig-oauth-audience/

   - HT: overview & intro - calls will continue work
   - HT: We will schedule conference calls to progress the work.

 * Rechartering and Future work (all)

  - HT: what should we be working on next?
    - MJ: proof-of-possession (aka Holder of Key)
    - multiple +1 from the room
    - Justin (jabber): token introspection!
  - app security - NS
    - Describe security issue with iOS: multiple apps can register for the same
    URI scheme
  - JSON metadata for OAuth Responses 1.0 - NS
  -  TL: how do we handle error codes - should take a new look at that
  - TL: need a mechanism for discovery of AS capabilities

  - CoRE authorization (CB)
    - CoRE introduction
    - HT & DA: make preso for CoRE wg for next IETF describing how OAuth could
    work for CoRE. CoRE group will inform OAuth about progress as requirements
    are more clearly specified.

  - User Authentication for Clients - PH
    - PH: multiple blogs about this problem: user auth being used for OAuth
    instead of OpenID Connect etc - PH: gap for authentication-only case - LJ:
    simplicity argument never ends - NS: user_info endpoint is optional in
    OpenIDC - NS: also why use separate claims? by changing the claims you have
    written a compliant OpenIDC profile.

- HT: session ajourned