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/
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
