F2F minutes Tuesday 3rd February 2004 (morning)

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

SSTC F2F Tuesday 3rd February 2004

Roll-call (attendee list in separate email), volunteer minute taking, 
meeting is quorate (19 present - at that time)
Hal - logistics discussion
Rob - thanks to BEA for hosting
accept minutes from last focus call
objections (none), minutes for Jan 20th meeting accepted
Rob - review agenda, SAML IOP concall at 1:30, editorial meeting then 
re-convene for session discussion, then SSO Profile enhancements, and 
enhanced client profiles.
Tomorrow 930 start. Hal noted XACML call at 10-11 Thursday is in 
conflict. Prateek will fiddle the schedule to work.

W2 - Identity federation

Rebekah Lepro not here?

Some confusion
Stick to original plan.
Reviewing interim draft 03b
Section 2.3 first modified section.
Eve/Scott - NameID section moved up in document. Now a BaseNameID that 
underlies both string-based and encrypted element NameIDs. New element.
Prateek - replaces 1.1 NameID
Is it backwards-compatible? "morally" compatible - Eve
John Linn - NotBefore attrib - is it bound to the time of encryption? 
Post-dated identifiers?
Scott - no use-case in mind, but use of temp NameID. If proposals for 
SSO were adopted, use for timestamps would only be for encrypted 
NameIDs, and NotBefore would be the time of encryption.
Hal - text implies tie between auth and encryption. No sense in a timestamp.
Scott - can decrypt Kerb tickets at any time.
Hal - time encrypted has no relevance, only signature is relevant
Scott - this is normally symmetric encryption
Hal - having this info is generally useful.
Scott - timestamp is there for privacy protection - ie. NameID is rolled 
over frequently. Assertion will not be signed.
Hal - you can re-sign.
Frederick - why is this the time the encryption was performed?
Scott - purpose is that relying party can ensure that NameId was 
encrypted by right guy at some time party finds reasonable.
Scott - two basic use-cases. One goes away.
Scott - can we remove these attributes, based on the assertion validity 
period changes?
If you can change the NotBefore date, then does it have value to relying 
party?
Scott - needs some integrity protection

ISSUE: Consider removing NotBefore/NotOnorAfter based on sessions 
discussion. Sync up validity period (Scott)
ACTION: Scott to think about this more

Hal: Need to re-sign anyway
Scott - NameQualifier identifies issuer.
Hal - this becomes a mini-assertion.
Eve - Issuer is now an element based on NameID, not an attribute
Hal: What is logic for not making this more generalized?
Scott - sensed that it would be harder to say it was string type
Hal - uc is issue attrib assertion about an issuer
Why not encrypt Issuer's ID?
Hal - sharply limit the things you can encrypt
Scott - Issuer will be a "SAML authority". Default Format.
Eve - consider default Format value in schema. Could say that default is 
profile-specific?
Scott - uncomfortable relying on profiles
Eve - withdraws suggestion

ISSUE: Default attribute?

Scott - issuer not necessarily the same entity as signer of assertion
Greg - relationship between Issuer and metadata?
Hal - signer speaks for the Issuer

James Vanderbeek (Vodafone), Paul Madsen (Entrust) joined on call
Jeff - not carving out SAML concall

Frank Siebenlist, Von Welch joined on call

Scott - want to be able to say in profile that Issuer must be signer
Moves us away from cert modesl that exist
Hal - Subject and SubjectConfirm may have nothing to do with NameID of 
Issuer
Eve - should we change something?
What is your model for validating the Issuer?
Hal - your policy can be whatever you want
Scott - trust models about Issuer being assertion signer (or not)?
Eve - does trust-models doc speak to this?
John L - no

Bhavna, Sun, Timo, Nokia joined call

Eve - what would we say in text here?
General agreement that text is good
Scott - no problem to either define or leave undefined in specific 
cases. This is not inconsistent
Scott - sentence is innocuous, but has implications

Eve - line 1073, refactoring of request/response
Scott - added Issuer to request and response, to aid quick evaluation of 
request
No authority that writes assertions in a certain way - leave it up to them
Scott - explains RelayState presence in req/resp

Eve - difference in queries
Scott - all stuff that used to be in individual requests (Assertion, 
Artifact etc) is now in a base type. Now WSDL can reflect individual 
support of protocols (I support AttributeQueries but not other types)

Scott - response is how you send back StatusResponse with 0 or more 
assertions.
Tim Moses, Entrust, Emily Xu, Sun on call.

Eve - NameIdentifier element ref'd is no longer general enough in 3.3.4.1

Federated RNI - new protocol
Scott - IOP Issues around it, with Format, NameQ. Explains RNI protocol 
messages.
Prateek - only IdP?
Scott - no, SPs too
Prateek - privacy is key here - this is why RNI exists.

ISSUE: any place we bring in Liberty work, we need to check assumptions, 
because Liberty assumes certain things about protocols. Specifically, 
check usage of non-federated id in RNI. (Scott)

Assertion vs. Artifact - Eve suggests ArtifactRequest and 
AssertionIDRequest both return an assertion, so names should reflect that.

Scott suggests that they are different.

Eve ArtifactRequest is RequestByArtifact

Hal - should be 1-1 assertion to ID, whereas artifacts can be one to 
multiple assertions

Eve - actual wording looks good.
Eve - blocked substitution in schema
Eve made distinction between normative and non-normative references
Hal - is Unicode normative?

Rob - OASIS is submitting SAML 1.1, XACML 1.0 to ITU-T
Hal - they will roll forward with new standards, things will be easier 
because of this submission.
Eve - how do we see this spec. suite? We have several specs. Entry point 
into suite is currently SAML conformance document.
Jeff - write intro document that does this (like LDAP).
Hal - SSL issue
Scott - inserted text about attribute values - multiple attribute values 
(lines 828-830)
Eve - null AttributeValue can be ommitted. AttributeDesignator holds the 
name. Eve proposes element MUST be ommitted.
Scott - ambiguity for null string.
Greg - finesse by saying 'has no value'

Agreed - If the attribute exists but has no value, then the 
AttributeValue MUST be omitted.
Scott - more controversial RECOMMENDED (82() each value appears in its 
own AttributeValue.
Irving - why not MUST?
Scott - trying to be loose with this, as there are use-cases
Eve - great to have structure there if you want to use it
RLBob - say more about this

Eve - moves to accept Core 04 as a working draft of the group, Jeff seconds
Any discussion? No,

VOTE

Any objections? None, accepted.

W2, 28D done
Adjourned till 2:30