[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Minutes for Focus subgroup 22 May 2001 telecon
Attendance Straw polls (Y yes, N no, A abstain) ========== #1 Gavenraj Sodhi Y Irving Reid Y Hal Lockhart Y Tim Moses Y Nigel Edwards A Dave Orchard - (temporarily absent) Gil Pilz - (temporarily absent) Darren Platt Y Eve Maler Y Marlena Erdos Y Jeff Hodges Y Zahid Ahmed Y Evan Prodromou Y Bob Blakley Y Thomas Hardjono (prospective) At 01:41 PM 5/21/01 -0400, Eve L. Maler wrote: >Running list of ACTION items >============================ >ACTION: Bob Blakley to develop and circulate a Word template for all >specification contributors to use. STATUS: no progress yet; try for >Monday 21 May. > >ACTION: Bob Blakley to work with Phill Hallam-Baker to develop the >simplified architectural model and coordinate it with the proposed >Core Assertions design. STATUS: BobB understood this as simplification >of assertion data structures, rather than as model as a whole; about >done with that. > >ACTION: BobB to update assertions based on Phil's new doc. > >ACTION: All members to review Phill's spec. Phil will be away till ~29 May; >comments should go to the TC list. > >ACTION: Conformance group to start reviewing the traceability >of use cases against Phill's design and release a rough draft for review >before the next TC telecon. > >ACTION: Prateek to do traceability review before the next TC >telecon. > >ACTION: Hal Lockhart to publish a fresh issues list. New deadline: To >be done by 18 May. DONE 22 May >ACTION: Hal Lockhart and Dave Orchard to update the Architectural >chapter to reflect F2F #2 decisions. Getting done. Hal to update your diagram. >ACTION: Agreement that for now session stuff should be taken out, >cardinality information and other changes should be done. DaveO to send >out chapter by Friday 18-May. DONE >ACTION: Jeff Hodges to update the Glossary to reflect F2F #2 decisions. >New deadline: to be done by 18 May. New deadline 25 May >ACTION: Darren Platt to update the requirements document to reflect F2F >#2 decisions and publish as a consensus draft ASAP. To be done by 18 May. Darren will send his draft to the TC for brief review; we will entertain a decision to publish it officially by the next meeting (29 May). >ACTION: Darren to add new requirements to requirements doc. DONE >ACTION: Eve to create Evite page with F2F #3 information. Deadline 23 May >ACTION: Prateeek to produce draft of bindings doc to go to whole >group by Tuesday 22-May. In progress >ACTION: Dave Orchard to send out URLs for XML protocol related >to binding. DONE >ACTION: Hal to add new issues. (Are AnonymitySupport, DisposableValidity, >TimeSkew, NameVsHandle, and ValidityDependsOn good names?) DONE >ACTION: Prateek will create or point to a use case for ValidityDependsOn. In progress New issues list =============== Hal described the new color scheme: previously closed issues are gray, newly closed issues are blue, and open issues to be considered this time around are yellow. Other open issues are not distinguished with color. It was suggested to reflect the status of each issue in the titles and the TOC, and to make sure that the distinctions. Hal will try to do this in the next revision. We agreed to use a 75% approval standard for this group's decisions on whether to recommend issues upward to the TC. We will tend to do straw polls on telecons, but if there's a need to resort to an official vote (e.g. by email), we can do that. NEW ACTION: Jeff will give Hal comments on adhering to the document guidelines. >Issues to discuss this time >=========================== >I would like to develop several recommendations during this call, so that >they can be considered at the 29 May call and we can make official >progress. Here are the topics I suggest: > >- WildcardedResources: To what degree is it useful/necessary/practical > to make requests about implicit lists of resources? To what degree > can we rely on XACML to buy us some of this, whenever it's done? DS-2-01: Wildcard Resources: (Focus group proposes to close it) Nigel: It could cause scalability problems to require each resource to be enumerated. A simple wildcard at the end of a URL might help a majority of the cases. SPKI has a powerful syntax for doing wildcarding. Jeff: Uncomfortable with SAML doing this. This is a job for XACML. Hal: There hasn't been any proposal that SAML be a provisioning protocol (where someone can load up a bunch of policies so it can act on them). SAML is supposed to be responding to a query about accessing a specific resource, and not providing information about unasked-about resources. Evan: We don't have a language for describing resources yet, so what's passed could be anything so far. Eve, Dave: URIs are dangerous for identity comparison already. Evan, Hal: Should attribute authorities ever need to mention resources? It doesn't seem so. BobB: Wildcarding is useful for caching, so you don't have to ask similar questions later. Jeff: This is a red herring, since we have a non-goal about defining a policy language. Nigel: Wants to use SAML to allow things like an entity in one domain issuing assertions that grant access to resources in another domain. Hal: There are two issues: different domains and multiple vs. one resource. Evan: What if we were to allow several different kinds of syntax for identifying resources, and then have an attribute that says which syntax was used in each case (e.g., one of them could be XACML)? Hal: But then you have to define each of the kinds of syntax. BobB: This is similar to defining an OID and then have registration of new syntaxes, which is a big pain. STRAW POLL #1: Do you agree or disagree with the following statement? "We recommend that the design not incorporate any provision for wildcarding for resource, as doing this is essentially to accomplish a policy statement, and policy is out of scope for SAML (draft-sstc-saml-reqs-00 page 6)." Gained sufficient support (~92% of those on the call). RECOMMENDATION: We recommend that the design not incorporate any provision for wildcarding for resource, as doing this is essentially to accomplish a policy statement, and policy is out of scope for SAML (draft-sstc-saml-reqs-00 page 6). >- CertsVsPasswords: Do we have a bias about which to support more readily? > If so, can we justify it, or should we get rid of it? Hal: Should this be an issue? A long time ago, we agreed that authN assertions would say how authN was done. The pass-thru subgroup will make a proposal, which will address this issue. Jeff: Agrees. This isn't a real issue; we won't list it. >- URIsForAssertionIDs: What are the pros and cons? What other methods > are there? DS-4-04: URIs for Assertion IDs: (still open after today) Eve, with help from Dave, gave a short tutorial on the problems with URI identity in XML namespace names. Thomas: The DOI people are working on this general problem. (http://www.doi.org, http://www.handle.net/) Eve: It would be acceptable to use URIs if we apply constraints. E.g., they should be absolute (or even should be absolute URNs) and we should define what equality means. Dave: Solving the "whole URI problem" is way bigger than SAML's scope. Jeff: There was recently an IETF BOF on the future of URIs, and W3C was investigating these issues, but nothing has really happened. Eve: See W3C's Character Model spec for recommendations on normalization and internationalized URIs. (http://www.w3.org/TR/charmod/) Dave: Cautioned that we have to be concerned with real-world websites and their behavior, which is not precisely the same as the standards. For example, http://www.jamcracker.com and http://www.jamcracker.com/index.html point to the same resource, but how can people know that? BobB: Aliases, symbolic links, etc. are a problem if you have policies on different aliases that conflict. Hal: We can take a hard line on URIs for assertion IDs, but for resources, we may have to deal with the vagaries of real-world URIs. Evan: URIs are opaque strings, and XML makes data's structure more transparent. Hal: There will probably be more cases than just AssertionID where identifiers will have properties of uniqueness (RequestID?) and are just "internal to SAML." We should pull out the description of these properties into a separate section and have it referred to from the various sections. Hal: We should register a new URI scheme, e.g. "saml:" Thomas: We could just use URNs and have the same effect. Jeff: It's pretty easy to register a new scheme with IANA. (http://www.ietf.org/rfc/rfc2717.txt) Eve: It's surprisingly hard to register a new URN namespace (http://www.ietf.org/rfc/rfc2611.txt) NEW ACTION: Jeff to send out email about possible URI constraints and identity definitions we should consider imposing in the case of SAML's unique identifiers. >If we happen to fly through these, I'd like us to walk through Phill's >latest documents together and capture any concerns: > > http://www.oasis-open.org/committees/security/docs/draft-sstc-core-07.pdf > >http://www.oasis-open.org/committees/security/docs/draft-sstc-core-phill-07.pdf DS-4-01: Top or Bottom Typing: (still open) Dave: The bottom-typing approach could be consider quasi-mixed content, with freedom to provide lots of different configurations. We should have tighter "type-checking" so that we push more work into schema validators. One thing that's missing currently is the cardinalities. BobB: He thinks Phill intends to distinguish assertions on the basis of what their Claims sections contain. Dave: Then the Claim becomes the type. Eve: In XML, ideally, you "type" things early (in document order) rather than late. Irving: But you don't want to have to reconfigure your software every time you add a new assertion type; you want to share elements wherever the basic housekeeping processing is the same. Hal: But we have a very small list of assertions. BobB: How far into the processing should you be able to get before you discover a problem? Tim: The argument Phill has used is that he would like to go up one level in abstraction. Hal: The subject/object paradigm seems obsolete; there are more modern systems. He may add an issue about this. -- 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