Subject: [OAUTH-WG] rough notes from 20100-03-04 meeting

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 05 Mar 2010 21:51:20 -0700

As copied from http://etherpad.com/RZilFVrF2Q (one of these days I hope
we'll get a chance to listen to the recording and correct the notes)...

***

OAuth WG Interim Meeting, 2010-03-04

* NOTE WELL: http://www.ietf.org/about/note-well.html

* Collective note-taking via EtherPad: http://etherpad.com/RZilFVrF2Q

*  Agenda bashing

None.

* Intro

Peter starts the meeting. Talks about the survey Eran had sent out and
the feedback being provided. David and Eran provided a proposal for the
way forward based on the feedback. Peter liked that.

* Chair announcement

 Peter can't serve as co-chair going  forward because he was named Area
Director, so the search is on to  replace him as co-chair with Blaine.

* Discussion of the "WG Survey" thread and results

Eran believes that people got confused with the different draft pieces.
People are waiting for a document "OAuth 2.0" to look at and to review.

Eran says that a number of people want signatures although he is not
compley sure why. The details about what has to be signed has to be
investigated.

Eran is working on a merged specification (the existing spec with the
WRAP spec) with David. Eran tries to preserve the roles because OAuth
1.0 has a couple of roles combined. Eran wants to have a draft ready for
Anaheim. He will miss the deadline but it will be ready for the meeting.

Peter: perhaps Eran and David can present about this at Anaheim

Eran: will work toward having a presentation

Hannes: I don't think that the scenarios presented provided enough
information to help us make decisions about security considerations
(signature methods etc.)

Eve: sounds like we need use cases as a way of drilling down into
security considerations, see also UMA work on exploring how to do UMA
over WRAP

Hannes/Eve: perhaps need to differentiate between use cases / scenarios
and design constraints

Dick: Could you clarify whether there are some scenarios that cannot be
covered by WRAP?

Eve: This is covered. We have 4 entities that are interworking - 2
interworking WRAP profiles. A single instance of WRAP would not be
sufficient.

Dirk: I am not sure what you do not have in WRAP and we should discuss
them on the list.

Peter: It might be helpful for the meeting in Anaheim to have some
presentations on the overview on the space and the history (OAuth 1.0 ->
WRAP, etc.). It would give those a bit of context for the discussion who
have not been involved in the work so far.

Dirk would be happy to talk about WRAP at the meeting.
David would give a presentation about the history.

Hannes: what has been settled regarding security mechanisms?

Eran: looking at 1.0, plaintext replaced by bearer token

Plaintext goes away -> replaced by WRAP bearer token
HMAC + RSA signature mechanism from OAuth 1.0.
Normalization ?(missed that part)? [we can listen to the recording]

TLS: OAuth 1.0 already requires TLS for transport of plaintext credentials.

Most crypto libraries will do things like SHA-256 and HMAC

Eran: if we take everything that WRAP has and the two signature methods
from 1.0, what use cases would that not solve?

Justin: Has anyone expressed a use case that requires a message to get
signed? I posted a use case but I am not convinced. Why do we need
signatures and not just TLS?

Eran: We require TLS anyway. Some people claim performance in a mass
scale deployment. I don't have the performance data. I have  a use case
for the asymmetric signature. [Where is it?] I don't see the benefit of
having an HMAC instead of using a plaintext token over TLS.

-- Discussion about OpenID --

Justin: Do we have scenarios that really need signed messages?

Dick: Keep in mind that the server is signing and not the server. So,
the comparison is different.

Eve: concern in the UMA community about relying only on SSL and would
like the option of signing the message

Dick: that would be useful because we would have clear requirements

Eve: as one example, outsourcing resource access (e.g., bookkeepers,
health data)

Dick: is there a secrecy requirement as opposed to a signing requirement?

Wolfgang: Encoding policy information into the data?

Eve: Privacy, security, and access control

Dick: Confidentiality of request and response?

Wolfgang: what is the holder of the token allowed to do?

Eve: Holder-of-the-Key assertion equivalent would be needed here too
(reference to the NIST level).

Brian: Thanks for the reference to the Holder-of-the-Key assertion.

Brian: do you need confidentiality in addition to integrity?

Hannes: you have a pointer to the key and the sender of the assertion
has the corresponding key that is mentioned in the assertion

Brian: if using SSL + bearer token, there are caes when insufficient:
... intermediaries that can access cleartext in the middle, don't want
tampering (need holder-of-key token)

Hannes: that's a separate question, a few ways to solve it: (1)
holder-of-key token (2) authorization step afterwards

Brian: are we going to do everything that WS-* provides in terms of
confidentiality?

Hannes: but this is going to introduce complexity

Eve: removing signatures takes away an existing capability

Brian: the requirements people have here seem to be more complex than
are handled by OAuth 1.0

Blaine: the use case I have in mind comes from looking at actual
deployments that are using signatures right now

Brian: but I think that is a fundamentally different requirement than
what Eve is talking about

Blaine: States that people inthe survey say that they want to keep the
signature mechanisms but then they do not have good use cases for them.

Peter: We need to have a discussion on the list about the use cases and
to determine what signatures technologies are needed. We need this input
till Anaheim.

Dick: we were not suggesting to pull the signature stuff, but understand
what the goals are, let's get clear on why people think they need signatures

Eran: Is the requirement for accessing without TLS a real use case? Is
the argument that TLS requests for resource request too expensive and is
it indeed more lightweight? I don't know the answer to that. This seems
the main reason why signatures come back.

We need to have a discussion about this aspect on the list.

Dick: In the WRAP spec the requirement for the TLS is between the client
and the authz server  (and not anywhere else).

Eran: Someone has to raise a hand and say that they want to use a token
with a signature mechanism without using TLS. Has there been any study
on how they are planning to do it?

Peter: There might be use cases where people though they couldn't do the
TLS case. And, are there other use cases where some people need the
signature based mechanism together with TLS (as Brian mentioned).

Eran: We have already a requirement that TLS will be required for some
pieces of the protocol. Do we need a way of presenting the token without
TLS usage?

Zachary: so, is there consensus that signature is an option without TLS?

Hannes: that's in 1.0, yes -- the question is do we need that going forward?

Zachary: I think it should be an option in OAuth 2.0

Hannes: but we need to be clear on why that's needed

Blaine just sent a mail to the list with the questions about the
signature mechanisms.

Zachary: Has some scenarios and will send a pointer to the list.

Peter: would it be helpful to have a scenarios document?

Zachary: yes

Eran: it would be helpful to have requirements and scenarios written
down, because if you can't write it down then you don't have a real
requirement

Peter: Asked to have 2 persons to volunteer for such a scenario document.

* Discussion of possible goals for Anaheim meeting and possible agenda items

AGENDA ideas:
(1) history / 1.0 (David, 10 minutes?)
(2) WRAP (Dick, 10 minutes?)
(3) melding of approaches (Eran/David, 20-30 minutes?)
(4) discussion about technical and security issues
(5) use cases / scenarios as WG item (5-10 minutes)

* Other business?

None

Action Items:

(a) Blaine to post to the list about signature methods (done)
(b) chairs to post rough agenda
(c) chairs to post about scenarios document and possible editors
(d) Eve to post about gap between UMA needs and existing WRAP
(e) Eran and David to work on slides about merged approach
(f) WG participants to log their technical/security issues on the list
for discussion in Anaheim

***

Peter

-- 
Peter Saint-Andre
https://stpeter.im/