Web Authorization Protocol (oauth)

1540-1710 	Monday Afternoon Session II 
Room: Boca 2


- Hannes Tchofenig (HT) opens session. Second session scheduled for Thursday.
- HT on milestone update
- Derek Atkins (DA) on interoperability issue raised by IESG.
- Mike Jones (MJ) at mic on interop testing. DA: we'll cover this later.

- Brian Cambell (BC) on OAuth and Assertions. 
	- 3 drafts
	- DISCUSS from IESG, interoperability concerns
	- report back from lunch discussion earlier in the day
	- presented SAML and JWT examples for tokens
	- Prateek (P) "examples are very different in information content"
	- BC: "yes - somewhat oversimplified"
	- Barry Leiba (BL): "is this relevant?"
	- BC: "no, but..."
	- BC, HT discussion around what comparisons mean
	- John Bradley (JB): "SAML impl often depend on correct configuration. Comparisons are always string exact match."
	- Prateek: "audience is a string that limits liability"
	- JB: "a string but important as it protects agains replay attacks"
	- BC: "Prateek: originally true but in practice it is used for validation"
	- HT to BL: "will examples+clarification on comparison help improve the situation and resolve DISCUSSes?"
	- BL: "both parties in a SAML exchange need to understand SAML assertions, syntax & semantics in the same way. How do I write an implementation to match your implementation?"
	- Prateek: "SAML 2.0 has syntax, processing rules etc, why is the SAML semantics the issue?"
	- DT, BC & HT: "no that is not the issue"
	- BC: "the issue is comparison in general"
	- BL: "what happens when a JWT assertion is sent to a SAML endpoint?"
	- BC: "we rely on out-of-band information"
	- BC, MJ, LJ, etc: talk about registration, SAML metadata etc as a solution to this
	- BL: "we have a way forward - feel free to send early proposals by me"

- Justin Richer (JR) on dynamic registration.
	- JR: intro , existing implementations in OpenIDC
	- JR: close to a final form of the spec
	- JR: overview of the history of registration from UMA and OpenIDC inputs
	- JR: protocol walk-through
	- JR, LJ, BL: discussion of trust issues related to the use of https references for keys
  	- Tony Nadalin (TN): "I want to use assertions (eg SAML) for dyamic registration"
	- TN, JR: discussion around reuse of assertions for registrations
	- Prateek: "why is scope needed at registration?"
	- JR: "a client is typically tied to scopes the client is allowed to register for - a common permission model"
	- Prateek: "scope is a function of resource in several cases... puzzled"
	- JR: over to section 2 - client metadata
	- Prateek: scopes are tied to APIs in practice
	- JR: some of this is related to token introspection
	- JB: related to a discussion on the use of scopes and resources
	- Stephen Farrell (SF): question of the use of i18n (eg for use of multiple display names) leads to multiple registrations?
	- JR: probably
	- SF: we can't have the client send 100 registration requests...
	- BL: language types are a problem
	- JB: in OpenIDC we support language tags - could be "ported" to this spec
	- DA: how many have read the current draft?
	- HT: not ready for WGLC... huge progress with the document though!
 	- JR: finish walk-through - registration refresh is possible
	- Nat Sakamura (NS): registration client uri seems to be same as... why invent new?
	- JR: <make some point on link types that I didn't catch>

- Roland Hedberg (RH) testing.
	- RH: intro to testing, doing testing for OpenIDC and SAML2
	- RH: testing is important
	- RH: identified keywords as basis for testing
	- Pete Resnick (PR): "you're out of your mind! - 2119 should not be used that way, implementations will be worse for this"
	- Paul Hoffman (PH): "Pete is wrong. This is what you should be doing."
	- PR: "MUST and SHOULD should be treated almost the same, MAY also a trigger point"
	- RH: "yes that is what we're doing"
	- PR: "great, love it!"
	- JB: "ask first, bite second"
	- PR: "absolutely"
	- RH: more on the test approach
	- PR: "will also tell you which MUSTs are not needed"
	- JB, RH, PR: discussion on test-points vs requirements
	- RH: continue describing how the test tool works and what roles you assume and the structure of tests
	- PH: "did you create negative tests?"
	- RH: right now only positive test but we do have some
	- PH: "but you can handle negative tests?"
	- RH: yes
	- SF: somebody said no audio on Jabber
	- HT: background for this is was push-back from Eran and others on the lack of interop
	- HT: contribute to the code, use the tests!
	- TN: also looked at interop in MSFT, turns out the normative language is a small portion of test requirements
	- Mike Jones (MJ): talk through some potential tests that are not covered by normative language in the spec
	- MJ: will share this with Roland
	- HT: talk about further work in this area
	- RH: "not my intention to build the ultimate test-suite, must be community driven,openidc has continuous interop testing"
	- RH: "we should integrate attack-vectors in the test suites!"
	- PR: "good point"
	- JB: "openidc tests are on osis.idcommons.org"
	- JR: "MIT KC has expressed interest in hosting an interop event"
	- MJ: Thank Roland and GEANT for their good work (applause) & negative tests important
- HT: reminder about next session
- MJ: who are interested in talking about the non-normative testable report from MFST?
- DA & HT: close session, see you all thursday


1730-1830 	Thursday Afternoon Session III
Room: Boca 1	


OAuth Security (Phil Hunt):
- Use cases for security were discussed
	- Question 1 - Did we cover relevant scenarios
	    * No issues raised by audience
	- Question 2 - Are the scenario descriptions understandable
	    * No issues raised by audience
- MAC Computation
	- Brad Hill - Flexible headers mean attacker could change request without changing MAC?
	- Hannes - We need to look at this issue.
	- Stephen Farrell  - Who are you going to ask for review, other people have done similar things (e.g. DKIM).
	- Hannes - APPS area?
	- Stephen - SAAG maybe as well.
- How RS obtains session key
	- Option 1 - Key Transport
	    * Stephen Farrell - Most people say "key transport" meaning RSA key transport. Here you have a symmetric key preconfigured?
	    * Q from Jabber: How is the keying material protected in transit?
	    * Hannes: Protected using JWE applied to a JWT
	- Option 2 - Key Retrieval
	- Option 3 - Key Agreement
	    * Similar to 1, but client and server shuffle info around to create keying material (e.g. DH?)
	- Which mechanism should be MTI in the document, and what feedback on any option?
	    * John Bradley - Option 1. RS can publish info about itself than can be discovered by AS and use asymmetric keys and give loosely coupled infrastructure
	    * Prateek - +1
	    * Leif Johanson - When an entity self-publishes info about itself, you have to rely on security properties of HTTPS.
	    * John Bradley: In reality some sort of federation would be in place to help. E.g. could put this info in SAML metadata.
	    * Leif - should retain option to provide keys not references to keys to retain flexibility.
	    * (?) - Obvious resemblance to Kerberos. Consequences about mutual authentication.
	    * Hannes - should consider this stuff in writeup in document.
	    * Phil - preference for option 1. option 3 would also be easy. Less keying material in transport is a good thing as it gives attackers less leverage.
	    * Nat - Option 1.
	    * Jason (from jabber) - Option 3 should be MTI.
	    * Option 1 seems to be generally favoured.
Mike Jones - JWT update
- JWT spec essentially the same since mid 2011. Stable.
- JOSE WGLC in a few months. OAuth WGLC should coincide.
	- Mike Peck - Part in spec about applying JWE/JWS - might be useful about when you use one or other or layer the two.
	    * MJ - Guidance about using signing before encryption for legal and technical encryptions.
	- Jeff Hodges - Looked at JWT. Nested JWTs which have been wrapped with signed and encrypted - is there proper linkage to deal with certain types of attacks (Davies paper). Mentioned in last para in security considerations, could be talked about a bit more. Also can't find anything about linkage between layers.
	    * MJ - Discussion on mailing list or in hallway to discuss attacks.
	    * JH - Sent message to mailing list a while ago that has been dangling.
	- Prateek ? - Should lighten and just retain core elements in spec, then perhaps through access token profile add relevant stuff. Would clarify and make lighter weight
	    * MJ - Extension points through IANA, yes. However, subject is there is for a reason - e.g. Facebook attacks. This is not an access token, it's a security token (like a SAML assertion). i.e. claims about authn event.
	    * Derek - MTI does not mean Mandatory to Use.
	    * Hannes - Important for Access Token
	- (?) - Content type claim is support to have JWT encapsulated. Is it more useful to indicate to indicate JWS/JWT or JWT/JWT?
	    * MJ - Simple to test if it's a wrapper JWT.
	- Phil (?) - since you have SAML and JWT bearer spec for. Audience definition in OAuth is destination. Should flip it over because SAML has opposite meaning.
	    * John Bradley - Given 3 different ways to indicate recipient in SSO… Audience must be identifier of recipient or abstract notion of recipient…
	    * Prateek - SAML widely used, so ridiculous to say that's an issue of SAML.

Mike Jones - Interop data gathered so far
- All interop data gathered so far posted to list: http://www.ietf.org/mail-archive/web/oauth/current/msg11150.html