Minutes for focus group con-call, Dec 16

["Eve L. Maler" <Eve.Maler@Sun.COM>]

Attending:

Paula Austel
Scott Cantor
Peter Davis
Frederick Hirsch
Jeff Hodges (partial)
Maryann Hondo (partial)
John Hughes
John Kemp
John Linn
Eve Maler (note-taker)
Prateek Mishra (chair)
Tony Nadalin
Jahan Moreh
Mike White

			*		*		*

W-2, Scott driving the discussion:

Scott:
This is the Name Identifier draft, draft-sstc-nameid-06.  This is
the basic proposal for identity federation.

The first thing to address is outstanding issues.  Scott and Tony
exchanged email a couple of days ago; Scott came to understand
Tony's F2F comments, which led to Scott changing terminology from
"one-time" to "transient".  The text in the draft doesn't apply a
strict one-time semantic, and Tony was arguing against such a
semantic, so there doesn't seem to be an issue there.

The proposal has been out there for a while.  It mostly only
changed in response to Eve's comments on the structure.  She had
suggested moving some of the common attributes on the base type
to the new derived type.  By moving things like the Format
attribute in this way, it eliminates the need for complex
processing rules for Format when it's irrelevantly used.  This
simplifies things.

The only known outstanding issue from the list or other
discussions has to do with whether we want to continue using the
Format attribute as a catchall classification value that has
overloaded semantics (syntax + meaning) or whether we want to
rename, break out the functions, etc.

========
Terminology discussion:

Prateek:
Has a question about what might be the relationship between W-2
and W-2a (the SSO-based attribute work item), and how to think
about the two.

Scott:
One obvious real-world use case would be Shibboleth, where they
dealt with the existing SAML spec by creating Liberty also
independently created, a "handle" or "temporary identity
federation" or "one-time identifier" or whatever.  If all you're
doing is exchanging attributes, if you do it in-band, the real
problem is the need to have a subject of an attribute statement.

Because Shibboleth needed a call-back mechanism out of band, they
needed more. (lost the thread a bit after this, regarding one-
time identifiers that aren't used much therefore)

Prateek:
In Section 2 of the solution proposal, where definitions are
given setting up the general notions of accounts, federation,
etc., he's struggling with federation in its narrower vs. its
broader sense.

Fundamentally, federation is always about account linking, but
how is it accomplished -- a special identifier, or a proxy
identity driven off a few attributes?

Scott:
Real-world practice is that you don't strictly need an account.
In the attribute-based model, account linkage can be avoided.
The interactions with the SP don't take place on a 1-to-1 basis
with the principal but rather through classifying the principal
through attributes.  But Prateek is right that you *can* have an
account.

Maryann:
Are these term definitions intended to be integrated with the
overall glossary?

Scott:
Yes.

We could break the bilateral assumption that account linkage and
identity federation are equivalent.  We could provide a unique
definition for account linkage that includes but doesn't depend
on identity federation ("one can accomplish AL through IF or
through other means, such as exchange of attributes" or similar).

Maryann:
Agrees with this idea.

Prateek:
So account linkage becomes the umbrella term.  But can both IF be
accomplished without AL?

Scott:
As an example, his university has contracts with various SPs, but
Scott personally doesn't.  There's an agreement to provide
service based on attributes.

A lot of people have been using account linking instead of
identity federation, because the latter has become so overloaded.

Prateek:
The notion of identity federation could be particularized as
attribute-based SSO in one case.

Scott:
We need to stress the "identity" part rather than the
"federation" part in that circumstance, but he agrees.

Eve:
Though this proposal doesn't need to address attribute-based
account linking/identity federation, we may want to add glossary
terms for that.

Scott:
ACTION: Decouple the definitions of account linking and identity
federation.

Prateek:
ACTION: Propose terms to address the attribute-based case that
are consonant with Scott's terms.

========

Back to the technical aspects of the proposal:

Scott:
The technical proposal hasn't changed much.  The first basic
proposal is in the vein of Irving's proposals to genericize the
key elements in our spec.  Allowing for complex content models
(perhaps counterintuitively) doesn't make the spec more complex;
it merely allows people to do the things they want/need to do.
Because there's an abstract type, customizers would still need to
define their own type in order to extend the base.

BaseNameIdentifierType re-bases the old simple NameIdentifier on
top of this new complex one.  Only the attributes that
potentially apply across multiple kinds of NameIdentifiers are in
the base type: NameQualifier (just as before), SPNameQualifier
(new, in order to allow identity federation through a triple --
two providers are involved), NotBefore (new), and NotOnOrAfter
(new).  If you have an encrypted name identifier, you may still
want to communicate the public-information name qualifiers
outside of the encrypted block.  The validity-period attributes
are useful particularly for encrypted name identifiers.

Tony:
(missed question about use case)

Scott:
(missed one use case)

Another use case is to indicate how long the relying party can
rely on the value.  It doesn't relate to the validity of the
assertion, but to the "handle".  This can get weird if the
validity period falls within the validity period of the
assertion, and he can't think of a good reason.  We may want to
have processing rules around it, but it doesn't seem to introduce
ambiguity.

The old SAML V1.x structure is now relegated to a concrete
restriction of that base type back down to a string, and it
introduces attributes specific to string-based identifiers,
including Format (like it was before) and SPProvidedIdentifier
(new, motivated by the identity federation use case).

The two new SP* attributes are done in reverse fashion from how
they're done in the contributed Liberty material; the latter has
attributes for IdPs not SPs, but if given the chance they
apparently would do it over in the fashion Scott has proposed.

Prateek:
SPNameQualifier attribute?

Scott:
It helps to unambiguously identity the other provider in the
account relationship.  It might be on the basis of either
identity or attributes.  In the later text of the proposal, these
two attributes' values could be determined from context.  They're
optional, even in the context of account linking.  In the common
case, the account provider is probably issuing the name during
SSO.

Finally, the case of an encrypted name identifier is derived from
the base name identifier type, using XML Encryption elements.
(This is why we needed the ability to have a non-string-based
name identifier in the first place.) That spec already covers a
lot of encryption infrastructure, so we ourselves don't have to
say anything about a nonce etc.

The presence of NameQualifier attributes on both sides and the
schema-validity of the encryption piece are what allow for
determining what providers can decrypt the name identifier.

Eve:
The name of the Format attribute is theoretically problematic,
but not a problem in practice.  Other potential names might be
Interpretation, Scheme, or Schema, but she prefers Format, partly
because it's gratuitously backwards-incompatible to change it.

Scott:
Agrees.  But is it worthwhile to break out the syntax vs. the
semantics?

Eve:
Nah.  Since we just provide a URI so far, and it's modularly
kicked out to a foreign system, why break it down further?

Scott:
The three new proposed formats:

- Provider identifier: Allows you to issue assertions about
providers.
- The other two are the already-discussed use cases.

Eve:
Does the focus group have consensus that the proposal (barring
AIs noted above) should be moved forward at the TC level?  Does
anyone want to record any technical issues for the record?

(Silence indicating consent :-)

Scott:
Rebekah's proposal for adding structure to Issuer should ideally
use this proposal for NameIdentifier.

			*		*		*

W-3, Jahan driving the discussion:

Jahan:
Let's settle one thing quickly.  At the last F2F, we discussed
discovery protocols.  Did the TC agree to move ahead with the URL
method and not do anything with dynamic discovery?

Prateek:
Yes.

Scott:
Someone may come along with another protocol binding in addition
to HTTP GET, but otherwise, yes.

Jahan:
How do we get the use cases that were provided, and reconcile
them against the current proposal, which addresses web browser
profiles specifically and is very Liberty-specific?

Scott:
It's correct to identify a set of roles that a provider is
willing to play.  We (SAML) have a wider set of roles beyond just
SP and IdP.

Maryann:
These come from the SAML domain model, right?

Scott:
Yes.  We need to account for these.

Prateek:
There's a bunch of protocols coming out of ID-FF, and we have the
original SAML request/response protocol, and we need the union of
these two.

Scott:
Yes.  For example, a provider acting as an attribute authority is
not covered in Liberty, but we need to cover this.

Maryann:
What happened to the credentials collector piece in the domain
model?

Prateek:
This is an additional work item.

Eve:
Indeed this would mean that our domain model is also expanding
through our additional V2.0 work, so we need to union all of
this, not just the existing SAML domain model.

Jahan:
Perhaps we can settle on what part of the domain model is going
to be brought in to the metadata work.

Maryann:
She would like to work further on this, and will contact Jahan
(needs to drop off the call now).

Prateek/all:
What are the potential roles?

- Liberty -> IdP and SP (roughly SAML source site and
   destination site).  Do we also need specific client
   roles, e.g. LECP and other?
- SAML -> additionally has attribute authority, and
   "attribute consumer" in the SP role.
- SAML -> authentication authority and (if we still end up
   having it) PDP ("authorization decision authority").

Each role may support certain profiles, and in each case some
metadata may or may not apply.

Jeff:
The roles should be cleanly abstracted out, and the name "SAML"
shouldn't be in there.  IdP is effectively a SAML authentication
authority.  An attribute provider is effectively a SAML attribute
authority.  And so on.

The IdP may expose a SAML request/response protocol interface in
this role.  An attribute provider may do the same.

Prateek:
There's just SP, IdP, and AP (attribute provider)?  It seems so.

Jeff:
LECP also seems like a role.

Frederick:
A proxy certainly might have metadata.

John Hughes:
He can see a Kerberos agent having metadata.

Prateek:
A Kerberos profile would then have certain system entities with
roles.

Jeff:
Think of it in terms of profiles, and then a system entity can
don a role to which a particular set of metadata would usefully
apply.

Scott:
The ID-FF V1.2 work rationalized the metadata nicely for this way
of thinking.  But it's sort of the other way around from Jeff's
mental abstraction.

Jeff:
S'okay.

Eve:
So the ID-FF contributions were specific to browser profiles, but
are well prepared to have additional kinds of profiles/metadata
added eventually?  It seems so.

Scott:
ACTION: Review the final ID-FF V1.2 metdata specs to

Eve:
Is it okay for us to ship a V2.0 that provides profiles that we
don't simultaneously provide good metadata for?  After all, it
took us some time to collect the right experience with interop
for SAML V1.X.

All:
We'd rather not -- it's best for interoperability!

Eve:
Works for me!

Jeff:
Lots of people are already working and playing with the relevant
specs, so we should be able to collect this information in good
time.

Jahan:
Remember that we already have our own SAML metadata drafts, so
looking at ID-FF is good but isn't the whole story.

Jahan:
ACTION: Update the metadata draft if necessary according to the
latest ID-FF V1.2 materials.  (Scott will also review for this
purpose.)

Jeff:
The ID-WSF stuff, which is not contributed but is certainly
publicly available, defines additional roles on the consumer
side; we can perhaps leverage this terminology down the road.

Eve:
To summarize, it sounds like we need to further explore defining
consumer-side roles in the metadata and haven't come to definite
conclusions yet.

Jahan:
ACTION: Post to the list a summary of the need to define metadata
for more roles, and introduce the notion of an attribute provider
(AP) role.

			*		*		*

Next meeting: December 23.  THIS IS A FOCUS GROUP CALL, NOT A TC
CALL WITH QUORUM REQUIREMENTS.


Mishra, Prateek wrote:

> Relevant drafts for focus group con-call:
> 
> http://www.oasis-open.org/apps/org/workgroup/security/download.php/4036/draf
> t-sstc-nameid-06.pdf
> 
> http://www.oasis-open.org/apps/org/workgroup/security/download.php/3695/sstc
> -saml-MetadataDiscoveryProtocols-2.0-draft-00.pdf
> 
> 
> Additional comments from scope draft 11:
> 
> W-2:
> Base use case: support as described
> in liberty-architecture-overviewv1.1.
> pdf (3895) Sections 3.2.1 and
> 5.4
> Extension use case: includes use of
> "one-time" identifier as discussed in
> mail message 200310/doc00002.doc
> Need to reconcile these use cases.
> Solution proposal: draft-sstc-nameid
> (4036); also see liberty-architectureprotocols-
> schema-v1.1.pdf (3896)
> Sections 3.2, 3.3, and 3.4, along with
> the Shibboleth architecture at
> http://shibboleth.internet2.edu/docs/dr
> aft-internet2-shibboleth-arch-v05.pdf
> Original issues: see sstc-saml-1.1-
> issues-draft-02 (3690) DS-1-02
> 
> 
> W-3:
> Use case proposals: sstc-cantor-w3-
> metadata (4122) and
> 200311/msg00018.html
> Solution proposals: sstc-samlmetadata-
> 2.0-draft (3519) and sstcsaml-
> MetadataDiscoveryProtocols-
> 2.0-draft (3696); also see libertyarchitecture-
> protocols-schemav1.1.
> pdf (3896) Section 4, along with
> the Shibboleth architecture at
> http://shibboleth.internet2.edu/docs/dr
> aft-internet2-shibboleth-arch-v05.pdf
> Original issues: see sstc-saml-1.1-
> issues-draft-02 (3690) DS-7-06, MS-
> 5-08
> 
> 
> 
> -----Original Message-----
> From: Mishra, Prateek 
> Sent: Tuesday, December 16, 2003 10:21 AM
> To: Mishra, Prateek; OASIS Security Services TC
> Subject: RE: [security-services] proposed agenda for focus group con-call,
> Dec 16
> 
> REMINDER: We have a focus group meeting at 12 noon today. We will work
> through the items listed below.
> 
> -----Original Message-----
> From: Mishra, Prateek [mailto:pmishra@netegrity.com] 
> Sent: Tuesday, December 09, 2003 1:42 PM
> To: OASIS Security Services TC
> Subject: [security-services] proposed agenda for focus group con-call, Dec
> 16
> 
> Work through solution proposals for
> 
> W-2: Identity Federation
> 
> W-3: Meta-data and Exchange Protocol 
> 
> Relevant documents and links may be found in the work items and scope
> document (version 11).


-- 
Eve Maler                                        +1 781 442 3190
Sun Microsystems                            cell +1 781 354 9441
Web Products, Technologies, and Standards    eve.maler @ sun.com