[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Minutes of 1 May 2001 Security Services TC/Focus telecon
Minutes of the OASIS Security Services Technical Committee telecon and the Focus Subcommittee telecon 1 May 2001 Please note the ACTION items below. If you see anything that needs correction, please reply to this message. Administrative ============== - Membership report: new/removed members (Heather) New members: Valerie BeauBien, Gavenraj Sodhi. - Roll call (Heather) Attendance list to follow in a separate message, provided by Heather. Quorum reached. - Approval of Joe Pato as the Chair Pro-Tem Bob B moved to accept Joe P; Krishna seconded. Passed. - Approval of Agenda Agenda approved. - Approval of F2F #2 minutes [They had not been sent out at the time of this meeting, so they will have to be approved at the 15 May telecon.] Subcommittee reports ==================== - General Editor's report (Bob) Nothing interesting or useful to report. - Security / Privacy (Jeff) Nothing really to report; Jeff has been doing ground work/info gathering, expects committee to ramp up over next couple of weeks. - Conformance (Krishna) Slowly gaining momentum. Have received some comments, will make this into a doco. Looking at standards to get best practices for conformance. Critical issue is "how many cells in the matrix", ie, how many classes of conformance? Deliverable is basically an assertions markup language - what are we assuming about existence of PDP, PEP, etc. Need to look at this on a case-by-case basis, as in some cases, we don't care about what is behind the curtain and in some we do. - Bindings (Prateek) Prateek is preparing a presentation for group to work through. Will to try deal with (relatively) concrete examples of bindings. - "Focus Group" (Hal?) Eve published a synopsis minutes. Spent most of time talking about "indexical references" problem. Need to be more precise with term "standard industry browsers". Marlena is working on a document describing Shibboleth's approach to IRs. Looking to take up "XML assertion generality" issue (as discussed at F2F). Do we have one sort of assertion with lots of fields, or different assertions identified by type codes? Subsequent to meeting, Hal will be chairing session management group (Hal will send email to group to solicit involvement) - Issues list (Hal) Hal had agreed to take over the use case issues list and turn it into general issues list; hoping to get an updated list out in next couple of days. There are 6 "hot" issues and an attempt to qualify them Liaison reports =============== - DSML (Gavenraj Sodhi) No report. - uPnP (Maryann Hondo) No report. - XACML Krishna volunteered to be our liaison to this group. - XML Encryption (Jeremy) Jeremy reported that they are making slow progress (they have just release a requirements document and they have a very rough draft of a spec). New spec issues =============== None. Adjournment =========== The TC proper adjourned and the Focus subcommittee telecon began. Issue list ========== - Indexical Reference Problem The consensus is that there is no alternative in some environments, but we need to consider security threats carefully. There were some action items around requirements and terminology, but my sense is that we are done with this item. No discussion at this time - starting to flog a dead horse on this one. - MessageMeaning This led to general discussion of many undefined, but potentially useful definitions of terms. Eve seemed to be the main person who wanted to pursue this. No discussion. - AuthZ Decision Assertions This is still open. Would it be better to discuss a specific design proposal or are there general issues that could profitably be discussed? In some senses this is a core assertions issue that should be discussed in terms of a proposal. One issue is that people want to be able to define a really stupid PEP. One p.o.v. is that PEPs need to return more info, such as info on why request allowed/denied, or personalization type data. We should look at the Open Group standard as it allows for return signatures: yes/no decision with a separate output paramater. One issue is that PEP may want to specify additional info or not (ie only give me yes/no), PEP may want to qualify answer (such as within scope of validity periods, for example). Do we want a validity period of assertion vs thing that is asserted? Would like to use validity period of assertion with having PEP state additional temporal assertions in its own language There is a concern about PDPs that return a "yes but" answer: How do we interpret "but"? What if you don't know what to do with but? How do we determine to whom we pass back additional information, under what circumstances (eg when is "you don't have access now, but if you authenticate with "X" and conditions "Y" you will have access" okay). Reached agreement that we want to exclude the "yes but" option: we allow a "no" answer with the possibility of "hint" information for success next time. For a "yes but", we are not going to provide "yes but here is additional info to be used to say no if you don't want to say yes". Bob has been putting together a version of Phil's assertions on this type of topic and will try to fit this in. Joe P will help. If we put unique identifiers in assertions then we can put in a "blank form/template" defining the type of information you want back. You only get a (not necessarily proper) subset of the information back. Similar to DCE's template of requested privileges. David O pointed out that this is similar to something else (couldn't hear as he was too quiet - please provide more info). ACTION: David O to provide more information here. Tim Moses has a proposal related to this that we should look at. Boolean response is not part of assertion; status code would indicate "yes/no". Simple PEP looks at status code; assertion reaffirms question. This could cause problems if need to archive: need to rebuild status code + assertion for logging purposes. David would like to see whatever we do covered under assertions work, and he would like to see a proposal (that we can pick apart). Tim will take his work, add "examples" (req/resp for yes, no, and no/but decisions). ACTION: Tim to produce strawman proposal. - NoPassThruAuthnImpactsPEP2PDP (Renamed to reflect Stephen's apparent intent.) The decision to exclude Pass-Thru-AuthN may impact the ability to achieve PEP to PDP interoperability. Stephen to explain. No discussion. - XMLAssertionGenerality Should we have one sort of Assertion with different contents (as current spec proposes) or a number of assertion types with codes and specified contents for each. A related issue is: should there be just one sort of assertion reference or more than one. Use of XML mechanisms, such as inheritance may be useful here. Is there an issue around template or query format? David will write this up. ACTION: David O to write up template vs. query question. [Was this satisfied by his writeup on the different possibilities for query formats? See: http://lists.oasis-open.org/archives/security- services/200105/msg00002.html Or is there a "template" aspect he wanted to bring up too?] We will define 1 request and 1 response; binding group will define how to use this. Request will include a template for returned information/assertion, response will include this info. The hope is that there is no situation that bindings group will find that needs more than these messages. Goal is to come up with generic req/resp that can be reused throughout SAML conversations. - Enveloped and Enveloping (and Detached) Not clear if this is a narrow technical issue about how SAML assertions get digitally signed or a broader issue about how SAML assertions relate to other, associated XML content. -- Eve Maler +1 781 442 3190 Sun Microsystems XML Technology Development eve.maler @ east.sun.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC