Draft minutes for SAML F2F, Tuesday 3.29.2004 Morning

[John Kemp <john.kemp@nokia.com>]

Roll-call - 19 present, therefore quorate
arrange minute-takers -

Tue morn - JohnK
afternoon - Paula
Wed morn - John L
Wed afternoon - Paul
Thurs - Frederick

Accept minutes of last meeting - no objections, so approved
Review agenda
Hal would like to add an itemt to discuss ITU-T
Frederick - add item to discuss WS-SMS, STP
Tony - explains logistics - kitchen combination #542
Eve - review scope document + re-assess W12, W22, W23, W26
Re-assess W12 - attrib retrieval - anyone in favour? No - change to inactive
W22 - assertion caching - anyone in favour? No - changed to inactive
W23 - security workflow - no-one knows what it is - changed to inactive
W26 - dependency audit - prateek cared once upon a time, and explains -
Hal mentions use-case of making assertions about an issuer. Enhanced
Condition definitions could support this. Changed to 'inactive'.

Review liason activities:

W18 - SASL. Is this critical for 2.0? Kerberos profiles could use this.
Discussions ongoing, but maybe not in 2.0 timeframe.
W20 - ebMS - not for 2.0 timeframe.

Eve: Notes difference between active and completed - completed items are
basically "feature complete".

Eve walking through core - draft-08-diff
Ref the XMLNS spec. - we hadn't done that before. Mostly editorial
change to introduction.
We need to updated the contributors vs. the editors. Eve explains
difference between the two lists. Add to list of 1.1 contributors.
Rob mentions that Karl has given rules on contributors.
Eve discusses BaseNameIdentifier
(RLBob, Mike Beach arrive)
Eve reviews EncryptedNameID - Scott mentions 0 or more key distribution
for Enc NameIDs. Scott also mentions 'recipient' attribute for the key -
do we want to make that a MUST? Review at some future point.
AssertionURIReference - new element - should we mention that URN would
require "special" resolution? If URL - security token reference to a
SAML assertion. Scott - should probably ref SAMLBind - this is
de-referenceable using that binding. Eve/Scott discuss referencing
between documents.
Eve - re-ordered Issuer
Scott - re-ordered the ds:Signature element on suggestiong from JohnH
Lighting discussions - lighting fixed. Everything is Illuminated
Subject discussion. Irving wonders whether we're changing too much. Eve
mentions the migration document
Scott says it's Irving's fault.
Rob + Greg says this is simpler. Conor agrees this makes processing simpler.
Eve asks for volunteer to list changes. Scott says he'll write it up.
Jeff H will do this!
RLBob mentions problem between assertions and statements.
There is an implied semantic of a Subject linked to the Assertion - just
not syntactically.
DoNotCacheCondition languuge improved by Scott.
Conor - does this impact session established with SAML token?
FJH - this is policy

SessionIndex - Prateek objects to MUST NOT for globally unique ID.
Discussion. Greg thinks you need normative langauge for this. Mentions
use of the AssertionID.

Scott mentions use of AssertionID, and then asks Prateek what the
use-case is.
Prateek wants to generate the same session id for each SP.
Conor tries to remember what the use-case.

Conclusion:

Some (not mutually exclusive) Options:

1) Use AssertionID
2) Re-write language to be even more specific

Greg presents an option to include
JohnK to propose text to meet the privacy needs when using specific
NameID Format values.

Time for break.

Eve discusses SubjectStatement changes.
Auth Method - TBD at this meeting
Discussion of authentication statement vs. authentication context statement
Eve - better define the terminology of AuthnContext within that element.
AttributeDesignator - for further discussion during the meeting.
Proposal added as discussed at last F2F.

AuthZDecisionStatement - implemented decision to freeze.
Eve implemeneted changes regarding the derivation of protocols from
Request/Response
Scott - added Extensions element - modelled to be consistent with SOAP
header element - ie. multiple extentions within one Extensions (header)
element.
Discussion of ##any vs ##other.
Should use ##other.
Scott - should we have a wrapper element for extensions?
Resolution: change Extension to use ##other
Scott: strongly suggests we use a wrapper element for extensions, in
order to better be able to better determine the sequence of elements.
Eve - explains difference between anyType, any, and anyAttribute
Frederick - suggests unified model for schema extensibility (allow
anyAttribute on ALL extension elements). Maybe want to add attributes to
the Assertion?
Scott - argue Ann's question about anyAttribute.
Decision: 1) keep wrapper eleemnt 2) use ##other for now, and maybe
expand scope if we find a good reason.
Discussion of extension by extenders.
Tony: Provide method of reference extensions. If I have an extension
defined, and I want to reference it, how would I do that? Add
anyAttribute in useful places.
Discussion of status codes.
Scott made a list in one place.
Eve wanted to split them out.
Rob - we need to have these in both places - should alphabetize in the
list, and then refer to them in the protocol/profiles.
Rob: Do we have to expose this much information in status responses?
Scott: We didn't do anything gratuitously - tradeoff between usability
and security
Eve mentions use of Qname in StatusCodes for IOP causing problems.
SubjectQuery - SessionIndex - what does it mean that Subject is now at
the assertion level? Again we need to think about Subject-less-ness.
Query processing rules (line 1682) text revised for type hierarchy of
NameIdentifiers
Scott - revised text about what it means to match SubjectConfirmation?
Scott explains Authentication Request protocol - intent is to write a
general protocol that can be profiled for specific uses. There are many
complex things that you can do when authenticating. We took the Lib
AuthnRequest, and exploded it into fully parametized assertion request.
Profiles would then profile it down. Defined a vocab to capture the
players in several scenarios.
Hal: Why isn't this possible in current SAML?
Scott explains use-case
Conor - mentions Liberty use-case of authentication context - SP can
control the strength of authentication.
Hal + Conor converse.
Paul: Policy advertisement mechanism
Eve: Not policy.
Hal: Requires capabilities not specified.
Scott: Authority can't figure this out themselves - request should
specify input.
Scott continues - is this thing an auth authority, a credentials
collector? Or what?
Conor: Should be a separate discussion item on agenda
Eve: Have we become too general?
Hal: Need a general framework
JeffH: We need to review the profiles well.
Eve: Can we make some slides explaining this whole thing better?
Scott to try and present this succinctly.
Prateek: Lunch!