OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[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]