Minutes of 24 April 2001 Focus telecon

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

N.B.: We will try a new meeting schedule from now on: TC telecons (1 May 
and every other week thereafter) will be just *one hour* starting at noon 
ET, and whoever wants to stay on the line for another hour to discuss Focus 
stuff can do so.  The total number of meeting hours for the Focus subgroup 
will therefore be 3: 1 hour starting at 1pm ET on the "TC on-weeks" and 2 
hours starting at noon ET on the "TC off-weeks."  This week was a "TC 
off-week."  I will add this information to the group page.

			*		*		*
Minutes of the OASIS Security Services Focus Subcommittee telecon
24 April 2001


Attendance:

Ed Simon
Joe Pato
Gil Pilz
Hal Lockhart
Jeff Hodges
Bob Griffin
Darren Platt
Eve Maler
Sridhar Muppidi
Heather Hinton
Marlena Erdos
Mark Vandenwauver
Phill Hallam-Baker
Evan Prodromou
Stephen Farrell
Carlisle Adams
Dave Orchard
Tim Moses
Irving Reid


General
=======
#0 gives the muting menu on the teleconferences hosted by AT&T.

We think the TC calls can be just one hour, and the second hour can be a
focus subgroup meeting.

ACTION: Joe to send next week's agenda and offer to chair next week's
meeting.


IndexicalReferencesConsideredHarmful
====================================
Carlisle: This problem is a little easier if you use PK technology.  But
this puts heavy requirements on client software.

Line 117 in reqs-00 needs to be clarified.

Are signed/unsigned ActiveX controls acceptable?  Unlikely.  Different
bindings may cause us to add "optional" features.

We don't want to forbid indexical references (even Bob B. didn't propose
that); our issue name is slightly too pejorative.  It's more that we
need
to be especially cautious about them.  Shibboleth uses them and solves
the problem by having a complex flow from user to destination with
redirects back to the various authorities.

Let's clarify terminology: when we say "indexical reference", we
typically mean a reference to the bearer of a token (or, more generally,
the user).  But the problem of this mode of reference is general.

In the browser scenario, we often conflate using cookies to locate a
corresponding assertion and to serve as secure proof to verify the
binding.  These could be done separately.

Some think this is merely a problem of defining the bindings, but others
noted that references already appear in the strawman for our core
assertions.

An "indexical reference" is something like "a reference whose referent
depends on the context in which the reference was conveyed".



ACTION: Jeff to propose new R-Bindings wording around "standard
commercial browsers".  (Line 117.)

ACTION: Marlena to try and get the Shibboleth flow specification sent to
us.

ACTON: Phill to write up an analysis of this problem.

ACTION: Jeff to define "indexical reference" and "nominative reference"
and "descriptive reference" and "reference" in the Glossary.  Give
advice: Always try to qualify further with examples of the type of
referent being pointed to, for example "indexical user reference"
(bearer
token), "nominative assertion reference" (assertion ID element), etc.

ACTION: Jeff to do something to the Glossary to indicate that we should
be careful with "authenticator": either define it in the Kerberos sense
or use "binding validation" (or something like "validation of binding
(VOB) process") instead.  (Where "binding" here is used in a special
sense, and should perhaps have an adjective on it!)  Validation of
binding may or may not use an authenticator.

We believe Bob Blakley already has an ACTION to work with Phill in
fleshing out his "dark night" architecture/design diagram.


XMLAssertionGenerality
======================
Hal suggested that we take up the XMLAssertionGenerality soon.  Related
to this is the idea even though you use references to (the same kind of)
assertions for different reasons ("depends upon"-type functionality vs.
a specific binding that lets you pass a reference to an assertion
instead of the "live" assertion), ideally we want a consistent design
for the different cases.  Dave points out that we could have a schema
complex type for assertions, and then several different assertion
elements that are of this one supertype.  This could help with adding
sessions later (which could be done as an extended assertion type).


MessageMeaning
==============
Line 727 in spec-00.

Terms in this space, some ill-defined:

XML document (defined in XML 1.0, but often misused)
package
message
data island (an XML "subtree")
detached (with a hash as a reference)/enveloping (superelement)
   /enveloped (subelement) (from XML Signature)
wrapper
header/payload
foreign namespace
block (in the XMLP sense)

There are non-DSig cases of enveloped, enveloping, and detached.  For
example, a SAML message and a related electronic purchase order might be
in any of those relationships, depending on our ultimate design.

To a certain extent, our use of these terms overlap with their use in
specific protocols that we'll bind to.  We have to ensure that we're
clear where we mean their sense versus ours.

ACTION: Ed Simon to send a pointer to the W3C SOAP/XML Signature Note to
security-services.

ACTION: Dave to analyze these terms from an XML Protocol perspective.

ACTION: Jeff to (eventually) analyze these terms from a MIME etc.
perspective.


Other issues
============
Stephen suggested this new issue: PassThruAuthNMayHarmInterop:
There may be interoperability implications of our decision not to pass
through credentials.

ACTION: Hal to add this to the issues list.
--
Eve Maler                                             +1 781 442 3190
Sun Microsystems XML Technology Development  eve.maler @ east.sun.com