OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Minutes from the SSTC FOCUS Conference Call, September 7


September 7, 2004

 

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, Gary: Prefer that information appear above the level of subject confirmation.

 

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 Gary.

 

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, 1:30PM (Easterb).

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]