[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Draft minutes for Thursday AM
=========================================================== Day 3: Thursday, February 5 ACTION ITEM SUMMARY ACTION: Mike make arrangements for Austin F2F (Mar 30-April 1) ACTION: (Owner: TBD) Getting MimeType Registration ACTION/ISSUE: (Owner: Jahan) Assigning Identifiers to SAML Entities Rob: Convened at 9:36 Hal: Will be joining the XACML call at 10:00 Need to discuss Schedule and F2F Mike: IBM will host in Austin Discussion: reached concensus on Two full days Mar 30 - Mar 31 - and 2/3 days on April 1 ACTION: Mike make arrangements for Austin 09:30-11:00: Session 1 (1.5hr) Darren Platt presentation on PingID/SourceID protocol testing/scripting engine ...slides... Darren: Script based protocol tester - based on JMeter from Apache Rob: Can these slides be posted? Darren: Yes Jeff: What is Jython? Darren: Lets you exec Python form Java Scott: Also allows Java from Python Greg: Can this handle series of requests chained of the result of previous? Darren: That is why have have custom samplers Darren: configurable for role that system under test is playing Greg: can require multiple systems in testing and drive from MITM Darren: hard to do when using SSL Prateek: should be able to run specific test with specific input and provide result log Prateek: if this could play that early interop test role then that would help vendors Frederick: are you planning to offer this to the TC Darren: not fully planned out yet how this will be marketed John: I maintain vast amount of PKI test tools for fun John: but have not yet incorporated SAML - JMeter sounds useful Scott: if anyone in the TC would donate testing/conformance suites it would be good/appreciated John: We donated PKIBench for PKI testing Scott: Would address Burton group issues Darren: Burton group was impetus for this project Darren: marketing group is getting excited so may not be able to donate. Prateek: will you bring this to the RSA interop? Darren: that is the idea - but cannot commit ...more slides... John: do you use the standard schemas? Darren: yes. Scott: do the tests presume a Java implementation? Darren: triggers are Java based but drives tests over the wire Prateek: the TC could (if it willed it) could try to work in some way... Darren: if the TC would bless this as the conformance testing suite for SAML Greg: do not want to have it supercede the specs Jeff: Doesn't think the TC blesses anything Bob: if you want to OpenSource some of this it might work well Darren: will take back these suggestions - thanks for input W-19: HTTP-Based Assertion Referencing Goal: accept solution proposal Document: http://www.oasis-open.org/apps/org/workgroup/security/download.php/3651/draft-sstc-assertion-uri-01.pdf Scott: posted a long time ago - not a lot to say about it - enalbes wsse:STR Rob: is this just for bearer token? Scott: no - no additional semantics Scott: needed since we are Eliminating AuthorityBinding Scott: which is currently in the WSS: SAML Token Binding Frederick: versioning? Scott: may look into versioning via xml namespace on mimetype Ron: I don't understand how metadata is used here - is there a way to convey more than the assertion id? thinking about a signature that refs an assertion - and DNS sppofing or other attacks Ron: can we attach something more Scott: need to look into that - really something needed by the retriever - yes may be reasonable to have some ref to the authority in the wsse:STR Scott: AuthorityBinding was only giving location Scott: wasn't saying anything about who was given the information Mike: why is the processing different if the token is retrieved vs. provided? Scott: it would be fruitless to apply protection on the URI Scott: vs. protection based on the context of usage Ron: think his issues are addressed by signing the message (with the token) Rob: in the browser artifact profile - it is required that the requestor must be authenticated Scott: we say in the SOAP that you SHOULD authenticated Eve: this is out fist new binding in a while Scott: not really a new binding Rob: where would this be documented Frederick: wouldn't it be in the core Eve: I would think bindings is better - it achieves roughly the same thing as the assertion id request Rob: but it is bound to HTTP Greg: it is an incomplete protocol binding Scott: don't feel strongly either way - will defer to the editors Rob: how long will this take to get into the RFC (mime) Scott: also for WSS need a pair of attributes: identifier of the authority id the assertion id. Rob: if you have the URI you don't have enough? Scott: don't thing this is the right place to do this. Scott: some people want to use SOAP and only SOAP - need articular of what needs to go in the STR to get the assertion id request. Greg: would you parse the uri to get the assertion id? Scott: you might not have a URI - if you have one you should use HTTP. Prateek: is this an issue for us? Scott: not for us but for the WSS people here. Ron: it isn't an issue for me. Frederick: I am hearing that there is no issue. Ron: What I hear you saying is that unless we say more in WSS there isn't going to be way to use bindings other than URI. Frederick: it is up to WSS to address it if there is a need. Prateek: do we need to take the step of naming SAML authorities? Scott: yes - has been explicit in Liberty but not in SAML. ACTION: (Owner: TBD) Getting MimeType Registration ACTION/ISSUE: (Owner: Jahan) Assigning Identifiers to SAML Entities MOTION: Scott moves to accept proposal, Frederick seconds No objections, passed. Frederick: do we want to talk SOAP now? Mike: I am ready to do it now - or at next focus group (as long as it could still be included in 2.0) some discussion we may discuss at the end of the day or on focus group. Break now: resume at 10:10 11:00-11:15: Break 11:15-12:30: Session 2 (1.15hr) W-7: Discovery Protocol, Scott Cantor Goal: accept solution proposal Document: TAS Scott: Liberty has spec for cookie with hashed provider ids Scott: Problems if they have uris that must be url encoded. Rob: When will you have text. Scott: Text will come straight from liberty text. Scott: Liberty calls it an introduction cookie - I call it discovery. MOTION: By Scott, incorporate introduction cookie subject to appropriate SAML changes and implementation experience, second Greg. No objection, passed. Other Business Ron: Will send email to the list for each issue NEW ISSUE: Multiple Authority Signatures on Single Assertion Ron: 1st issue: SAML assertions carry an envelop signature with minoccurs=0 Ron: seems like an arbitrary limitation Scott: simple part si to say more than one signature Scott: if you want additional signature on addition claims John: countersign of assertion in its entirety works John: different claims should be in diff assertions and bound Hal: could be bound by exact match on subject Greg: might cross ref by assertion id Ron: assertion contains multiple parts statements about subject and key binding Ron: when sender vouches some other authority provides key binding Hal: why not just use multiple assertions? Prateek: still doesn't see the use case Ron: made a drawing on the board - will send to the list W-28b: Deprecating AuthorizationDecisionQuery and AuthorizationDecisionStatement, Prateek Mishra Goals: Make a decision! Document: TAS Prateek: Told XACML to not wait for SAML before proceding Prateek: Asked who is using it - Rebekah said NASA is - and XACML closed issue list for XACML 2.0 Hal: not sure that's true Prateek: so won't drop these in SAML Scott: can we import from 1.1 schema? Hal: XACML will do XACML specific one, would prefer not to see additional features added. Steve: they do not want to add too muc to their scope Bob: no one here is going to write the text to complete the item John: is the perception that it is broke? Rob: just not powerfull enough Hal: at the time it came XACML was not very mature and needed something simple Scott: freezing will mean some work - copy into the schema - not the amount of work - conceptually bringing it in requires work Rob: still need to do that if deprecating rather than removing Scott: can we reuse existing schema rather than pull it into ours in 2.0? Eve: to implement entire XACML to do simple auth may be too much Hal: any PEP can only provide info that it has Hal: deprecation could be non-specific about which version will not have it Hal: this additional functionality could be CD in XACML before SAML 2.0 MOTION: Steve moved to freeze this functionality as is for SAML 2.0, no further functional enhancements, with suggestion that anyone needing more functionality look at XACML, Hal seconds Discussion Rebekah: isf it is not deprecated I am comfortable with the motion as is No objections, passed. Lunch at 12:08, resume at 1pm=
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]