[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes from SSTC COnference Call, August 10
SSTC COnference Call, August 10, 2004
-------------------------------------
1. Roll call
36/41 voting members present.
Attendance of Voting Members
Conor P. Cahill AOL, Inc.
Hal Lockhart BEA
Rick Randall Booz Allen Hamilton
Ronald Jacobson Computer Associates
Gavenraj Sodhi Computer Associates
Tim Alsop CyberSafe
Paul Madsen Entrust
Dana Kaufman Forum Systems
Irving Reid Hewlett-Packard Company
Paula Austel IBM
Maryann Hondo IBM
Michael McIntosh IBM
Anthony Nadalin IBM
Nick Ragouzis Individual
Scott Cantor Internet2
Prateek Mishra Netegrity
Forest Yin Netegrity
Peter Davis Neustar
Frederick Hirsch Nokia
John Kemp Nokia
Senthil Sengodan Nokia
Charles Knouse Oblix
Steve Anderson OpenNetwork
Ari Kermaier Oracle
Vamsi Motukuru Oracle
Darren Platt Ping Identity
Jim Lien RSA Security
John Linn RSA Security
Rob Philpott RSA Security
Dipak Chopra SAP
Jahan Moreh Sigaba
Bhavna Bhatnagar Sun Microsystems
Jeff Hodges Sun Microsystems
Eve Maler Sun Microsystems
Ron Monzillo Sun Microsystems
Emily Xu Sun Microsystems
Mike Beach The Boeing Company
Greg Whitehead Trustgenix
James Vanderbeek Vodafone
Attendance of Prospective Members or Observers
Cameron Morris Novell
Scott Kiester Novell
Rebekah Metz NASA
Membership Status Changes
none
2. Hal Lockhart alerts SSTC to WSSTC "CD Draft" status for SAML Token Profile
Will forward/generate message with a link to the document.
http://lists.oasis-open.org/archives/security-services/200408/msg00092.html
3. Minutes from August 3, Conference Call accepted
http://lists.oasis-open.org/archives/security-services/200408/msg00024.html
4. General sentiment to work with dates specified in
http://lists.oasis-open.org/archives/security-services/200408/msg00091.html
Eve: conformance document will list all the normative documents.
Voice vote scheduled for August 17 as discussed on August 3 conference call.
Vote scheduled for first part of August 17 meeting.
5.
a. proposed new text for X.500/LDAP attribute profile
http://lists.oasis-open.org/archives/security-services/200408/msg00064.html
Scott: Proposes we adopt text, main change is a new encoding attribute specific
to this profile.
Conor seconds.
Call for discussion, objections. Motion carries.
b. Addition of more wildcarding
http://lists.oasis-open.org/archives/security-services/200408/msg00033.html
Scott: separate discussion of any attribute from discussion of ID attribute.
Initiates discussion of any attribute flexibility.
Proposal is to add schema flexibility of any attribute to all root elements, assertion,
request, response.
Eve: concern about this type of flexibility without concrete use-cases.
This can be achieved via schema-extension in any case.
Ari: Also prefers schema-extension as the correct route going forward.
Conor: concerns that a validating parser would fail with the schema extension model.
Scott: shifts to discussion of ID attribute issue. Suggests that by allowing arbitrary
attributes and making ID attribute optional in schema but required in prose,
in SAML 2.1, we can begin using the forthcoming XML ID proposal (still emergent).
Conor: Why don't we change schema in SAML 2.1?
Eve, Scott: dont want to make schema changes in a DOT release.
Ron: Have we discussed the possibility of an attribute choice at this level?
Scott: Not supported by XML Schema.
John Kemp: Feels a little odd that we are opening up our schema with a view to
incorporating as yet unknown XML attribute.
Scott: Make ID attribute optional in schema but required in prose.
Eve: Only a single ID attribute may be present but schema may include many ID attributes.
Ari: concern that we should not make changes based on behavior of popular parsers.
Eve: Motion to change the cardinality of the current ID attributes
in schema to be optional with prose making it required.
This is contingent upon schema permitting schema permitting
multiple optional ID attributes and implementations correctly implementing this rule.
Eve will resolve schema issue, Scott will resolve the implementation issue.
Tony: Why do we need to address this issue at this time?
Scott, Eve: Motion is withdrawn but with non-normative text in ID, IDRef section that
speaks to the possibility of a standardized XML ID attribute. Includes reference
to XML ID issue draft. Action to Eve.
c. proposed updates to conformance document
Conformance with identifiers/affiliations (long)
http://lists.oasis-open.org/archives/security-services/200408/msg00020.html
Re: [security-services] MTI security models for SOAP Binding
http://lists.oasis-open.org/archives/security-services/200408/msg00046.html
MTI Security model for SAML URI Binding
http://lists.oasis-open.org/archives/security-services/200408/msg00070.html
All of the formats and semantics in Section 8.3 of core are MTI
http://lists.oasis-open.org/archives/security-services/200408/msg00074.html
d. Comments on SAML 2.0 Core draft-19...
http://lists.oasis-open.org/archives/security-services/200408/msg00057.html
Why do we have separate attributes for MajorVersion and MinorVersion?
Can't we have a single attribute called version with a fixed decimal format (2.0).
Also, can't we make MinorVersion optional so that if it isn't present it defaults to zero.
This applies to the assertion itself, as well as the RequestAbstractType.
Motion: Replace the pair of attributes by a single attribute and update text accordingly.
Steve takes roll. Vote carries. Action to Scott Cantor to propose text and make changes.
Lines 560-565: The way this is laid out in the schema,
I can have 0 or more of the 4 statements in a random order. I would rather see this
done by removing the choice and then having the 4 statements listed with min=0, max=unbounded.
That way the statements of the same type all come together.
Irving: Why add order when it has no semantic significance to it? What about the case where
additional statement types are included.
Rob: consensus that this could be deferred to a future release.
Lines 722-731: These make statements as to the validity of the assertion based upon the
conditions. I think that it should refer to the condition check step in the validation
process rather than saying that the assertion is valid. So, if the condition is not met,
the condition check step fails. If the conditions are not specified, empty or all are met,
the condition check step is passed. I don't like the current statement on line 724-5
that says 'the assertion is considered to be Valid". Similarly, I would say that conditions
are met or not met (as opposed to valid or invalid -- the conditions themselves are (almost)
always valid, it's just whether or not they are met that is of interest here).
Action Item to Scott: Clarify text around 724/730 to say: assertion is considered valid subject to
other processing or contingencies.
Line 1873: Strongly recommend that IsPassive default to "false" not True.
The passive request is the exception to the rule and the default should be set accordingly.
Greg: The reason this defaults to "True" because the thinking was that URL-encoding would
be minimized with this default. This is the history in Liberty, my opinion is that we should
change it.
Motion: Conor, Seconded: Scott.
Motion carries with unanimous consent. Action to Scott to make changes.
Lines 1942-1946: I thing this is a bit watered down from what it should be. Essentially this
is specifying that the Requesting Entity is asking the Identity Provider to establish a
new relationship identifier (federation identifier) for the subject at the relying party.
I also think the default should be "False". Suggested wording:
A boolean value used to indicate that the requesting party would like the
Identity provider to create a new federated name identifier (if one doesn't already exist)
for the subject at the relying party. Defaults to "false". When "false" the AuthnRequest
should fail unles an existing federated name identifier exists for the user at the relying
party.
Scott moves, Conor seconds. Motion carries unanimously, action to Scott to make changes.
Line 1430: Status should not be required. If not present, it should be interpreted as:
<Status>
<StatusCode Value="urn:oasis:names:tc:SAML:20.:status:Success" />
</Status>
(Note that I think this awful lot of stuff to just say "OK".)
Jeff: Prefers to keep it this way. Prateek agrees. No change to specification.
c.
Conformance with identifiers/affiliations (long)
http://lists.oasis-open.org/archives/security-services/200408/msg00020.html
Scott: Strike first two rows of Table 3 Extended profile matrix, replace with language
that states all IdP, SP, support the name formats in Section 8.3 of core.
Nick: Seconds.
Motion carries by unanimous consent. Action to Prateek.
> 2.3 Security models for SOAP Binding
>
> The following security models are MTI for profiles that use the SOAP
> binding. The SAML requester and responder MUST implement the following
> authentication methods:
>
> 1. No client or server authentication.
>
> 2. HTTP basic authentication [RFC2617] with and without SSL 3.0 or TLS 1.0.
> The SAML requester MUST preemptively send the authorization header with the
> initial request.
>
> 3. HTTP over SSL 3.0 or TLS 1.0 (see Section 6) server authentication with a
> server-side certificate.
>
> 4. HTTP over SSL 3.0 or TLS 1.0 mutual authentication with both server-side
> and a client-side certificate.
>
> If a SAML responder uses SSL 3.0 or TLS 1.0, it MUST use a server-side
> certificate.
>
Greg moves, Mike seconds. Motion carries unanimously - Prateek to implement.
Scott moves that the same security model be MTI for URI binding, Jeff seconds.
Motion approved unanimously.
Eve moves that There were other conformance considerations included in
that document that we may want to bring forward (things like maximum
number of nested elements etc.). Scott seconds. Unanimous consent.
Scott: a section in conformance to enumerate all MTI signatures and encryption
in SAML 2.0.
Jeff seconds. Unanimous consent.
Scott proposes that a single matrix for IdP Extended, IdP, IdP Lite (and SP) be
maintained in the document.
Add text explaining that the matrix of implementations in Table 1 is an enumeration
of all possible profiles and implementations.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]