[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes from the SSTC FOCUS Conference Call, September 7
Rob Philpott Eve Maler Abbie Barbir Scott Cantor Prateek Mishra Greg Whitehead Ari Kaufman Irving Reid Nick Ragouzis Ron Monzillo Steve Anderson Conor Cahill Gary Ellison Bob Morgan Jeff Hodges 1. Gary Ellison:
Comments on core-2.0-cd-01 - Assertion Issuee http://lists.oasis-open.org/archives/security-services/200408/msg00250.html Scott,
Prateek: This is different from audience. This focusses
on the question of whether we need a way to capture to whom
an assertion was issued (and who will then present the assertion). Ron Monzillo:
Summarizes discussion with Gary Ellison. His interest is not so much the entity the assertion to whom it is
issued, as much as understanding when the assertion is being offered or presented by
an entity other than the original issuee. Greg
Whitehead: Isn't this the same as Recipient? Scott:
Recipient is related but enmeshed in SAML protocol particulars. The interest is in finding means to describe this at the
assertion level. Conor: Describes a use-case where SAML
assertions are being used with web services. Prateek: What
about the WSS SAML token profile? Relationship to this
discussion. Ron Monzillo:
Believes that WSS SAML token profile covers much of this use-case. Gary Ellison
(suddenly appears on call!): Reaffirms that his interest in his capturing the party to whom the assertion has been issued. Rob, Scott: refers
to his response http://lists.oasis-open.org/archives/security-services/200409/msg00012.html ..general discussion on around how many "issuedTo" labels might there be?.. ..What is
their relationship to the contents of the SubjectCOnfirmationData?.. Scott: Will
make proposal (consensus of focus call) to update based on his response to http://lists.oasis-open.org/archives/security-services/200409/msg00012.html 2. Gary Ellison:
Comments on core-2.0-cd-01 - SessionIndex description
http://lists.oasis-open.org/archives/security-services/200408/msg00251.html Editorial
comment that has already been applied to the draft by Scott Cantor. 3. Gary Ellison: Comments on core-2.0-cd-01 - NameIDType usage http://lists.oasis-open.org/archives/security-services/200408/msg00252.html Calls for a
single processing model for a class of identifiers, Scott suggests recipient discussion will resolve some of these issues. 4. Scott
Cantor: Proposal on removing or clarifying use of Recipient attribute http://lists.oasis-open.org/archives/security-services/200408/msg00253.html Scott:
explains that we have two instances of recipient in the specification. One is
historical and not currently used. Jeff: concern
about removal of attribute without carrying out security analysis. Greg: Points
out that SAML differs from ID-FF in that nameidentifiers
may have more well-understood information. Scott:
Proposal -- Add recipient attribute to the abstract protocol flow, clarify that
bindings will use the attribute. All front channel
bindings will reference use of the recipient. 5. Jeff
Hodges: Re: [security-services] proposed SAML artifact definition http://lists.oasis-open.org/archives/security-services/200409/msg00000.html Jeff: in the
absence of comment, plans to include in glossary. 6. Paul
Madsen: Rationalization of Usage rules for <Issuer> in profiles? http://lists.oasis-open.org/archives/security-services/200409/msg00003.html Scott has
closed in discussion with Paul, Paul's message
confirms this understanding. 7. Thomas
Wisniewski: ID Federation - Is there a notion/need of one-way vs. two-way
direction for it Scott, Rob:
The question is whether an SP in behaving as an IdP can re-use a previously established name identifier. This is OK provided all other
processing rules are observed. Doesn't
believe that there is anything to clarify here. Scott: raises
question concerning "NameQualifier" use ---
intent here is NOT to capture about directionality of use but to capture information about origin of the
identifier. ACTION:
Include in the implementation guidelines. 8. Prateek
Mishra: missing items from the glossary: session participant, session authority
This is an ommission (John Kemp's message) and will be added to the
glossary. http://lists.oasis-open.org/archives/security-services/200409/msg00010.html 9. Scott
Cantor: empty-valued vs. null vs. zero-valued Attributes (Suggested agenda item
for focus call) http://lists.oasis-open.org/archives/security-services/200409/msg00014.html One issue is
that the core disallows use of empty strings but this may be required for
attributes. We should
update the core text in the attribute value section to allow for this case. Second issue
is the following: Finally, I
note that while XML permits an element to be explicitly "nil" using the xsi:nil
attribute, this isn't permitted by our schema. If we wanted to permit "nil" values to
appear, we would need to add nillable="true" to the schema for the AttributeValue element. By default, anyType is not nillable. Third, case is
the null value which is currently covered by SAML 2.0. ..general discussion about this use case.. Scott:
Proposal that attribute values include empty string and
nil values. 10. Scott
Cantor: SessionIndex past discussion and proposed
text http://lists.oasis-open.org/archives/security-services/200409/msg00015.html This is the
text we would vote on next Tuesday, September 14. 11. Bob
Morgan, will send text changes on X.500/LDAP attribute profile, in time for
inclusion in next weeks call. 12. Call
adjourned, |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]