Minutes for Focus subgroup 5 June 2001 telecon

["Eve L. Maler" <eve.maler@east.sun.com>]

Attendees
=========
Irving Reid
Hal Lockhart
Fred Moses
Tim Moses
Dave Orchard
Gil Pilz
Prateek Mishra
Marc Chanliau
Jeff Hodges
Phill Hallam-Baker
Eve Maler
Marlena Erdos


At 01:13 PM 6/1/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.
>- Target date 1 June
>
>ACTION: Bob Blakley to propose simplified assertion data structures based
>on Phill's new document.
>- Target date 1 June
>
>ACTION: Prateek to do traceability review before the next TC telecon.

All continued to next week.

>ACTION: Jeff Hodges to update the Glossary to reflect F2F #2 decisions.
>- Target date 12 June 01

Not due yet.


>ACTION: Eve to create master bibliography and provide bibliography section
>for document guidelines.
>- Target date 5 June 01

Continued to later this week.


>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.

Done.

>ACTION: Subgroup leaders to get new materials to BobB (and security-
>editors list) by COB June 14 in preparation for publishing the F2F
>versions of the spec.

Not due yet.

>ACTION: Marlena to champion DS-1-02, Anonymity Technique, and confer with
>BobB and Phill.

In progress.

>ACTION: Hal to champion DS-3-01, DoNotCache.

Done.

>ACTION: Hal to see if the issue list text for DS-3-02, ClockSkew, is
>sufficient or needs more explication.

Done.

>ACTION: Prateek to champion DS-3-03, ValidityDependsUpon.

Continued.


>ACTION: Dave to champion DS-4-01, Top or Bottom Typing.

He sent a proposal that starts to address this.  But this is continued 
until he writes up a real votable item.

>ACTION: Jeff to champion DS-4-02, XML Terminology, aka Messages and
>Packaging.

Continued.

>ACTION: Tim and Dave to brainstorm further on how to proceed with DS-4-03, 
>Assertion Request Template.

Continued.


>Issues and concerns
>===================
>How to prioritize issues resolution?  Are there big topics that must be 
>taken up before we start "tweaking" the draft-core design in earnest?

We need to decide whether we're happy with the basic "shape" of assertions 
before doing further design work.

Dave walked through his new proposal, which is at:

   http://lists.oasis-open.org/archives/security-services/200106/msg00016.html

We briefly discussed whether Dave's "architectural principle #4" about 
using XML attributes for single-cardinality things is a good idea.  But we 
agreed this decision is separable from others and can be deferred as secondary.

Some of Dave's notes:

- A subject can have arbitrary attributes, and the notion of "role"
   is not treated as special.

- The required rights values for permissions in authZ assertions
   came from BobB's CORBA work, but that list can be changed.

- Naive implementations could store virtual assertion documents in a
   clear-text file.

We spent quite a bit of time chewing over the idea of using XML Query for 
doing SAML requests.  Some concerns:

- XML Query might not be a Recommendation in time (or even have an
   XML serialization of the language in time); its design might
   change out from under us.

- It's "opaque" as far as SAML is concerned, in that the semantics
   of the query are generic across all XML and don't have anything to
   do with assertions.

- The kind of query you can construct is open-ended.  It appears to
   allow (depending on the particular subset of XML Query that you
   choose) something way more powerful than wildcards, which we decided
   not to allow last week.  It would essentially be a policy store query.

- Policy queries are done in a bunch of ways today.  Those engines
   would have to be changed to be XML-aware, which may be difficult.
   (But is this a problem with the core-07 design as well?)

- People implementing a lightweight SAML system would have to implement
   the query handling from scratch, which could be onerous.

Particular reasons to be interested in XML Query:

- Working implementations (of the whole query language) exist already.

- XML Query works with XML already.

Phill noted that choosing XML Query will favor some schemas over others, 
e.g., it might favor a "toppish" design because it would be awkward to 
define queries against a "bottomish"-style assertion.

We agreed that using XML Query is not finding very much favor right now, 
but deferred a recommendation until we could discuss assertions themselves.

We identified the following areas where we haven't all been agreeing in our 
understanding of assertions:

- What is an assertion vs. a claim, and how does that map to our domain
   model?

- What assertions/claims need to be "plural" and which "singular"?

We found that Dave's class diagram was very helpful for drawing these 
issues out.  We settled on aliases for the three different levels of container:

- Top level: This is a fairly loose grouping that is probably most
   useful for collecting things before transport.  Dave's proposal
   called this an AssertionsList and Phill suggested calling this
   AssertionPackage.  We will call this "Compound" for now.

- Middle level: This is *very roughly* what the domain model calls
   an assertion, but it was easy to think of cases where it would be
   convenient to collect multiple subthings inside them (particularly
   attribute assertions) that might want to share the same assertion
   ID, Issuer, etc.  Phill's core-07 document calls this an Assertion.
   Dave's proposal had an Assertion element, and subtyped it into
   AttributeAssertionType, AuthenticationAssertionType,
   AuthorizationAssertionType, and DecisionAssertionType.  We will
   call this "Molecule" for now.

- Bottom level: This always does a single job, e.g. providing one
   attribute or one authentication.  Phill's core-07 document calls
   this a Claim.  Dave's proposal doesn't really seem to have this.
   (Dave, correct me if I'm wrong.)  We will call this "Atom" for now.

We started to get an idea of which accompanying info (SAML version, 
assertion ID, issuer, issuer instant, conditions, advice) might want to be 
shared among several "things" vs. uniquely specified, and the final answer 
to this question will do a lot to determine how we end up structuring the 
schema for assertions.  It could be fairly or literally recursive (all 
accompanying info could be shared by atoms, molecules, and compounds), or 
it could lock down the three distinct levels.  Some questions we will have 
to answer:

- Where would the request ID go?

- Where would references to other atoms/molecules/compounds go?

ACTION: Dave and Eve to come up with a small selection of diagrams that 
show different options in time for the next telecon.
--
Eve Maler                                             +1 781 442 3190
Sun Microsystems XML Technology Development  eve.maler @ east.sun.com