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 for Focus Call, March 9, 2004




Minutes from Focus Call, March 9, 2004
--------------------------------------
Attendance:

Eve Maler
Scott Cantor
Bob Morgan
John Linn
Irving Reid
Paula Austel
Jeff Hodges
Darren Platt



1. Eve leads group through 
http://www.oasis-open.org/apps/org/workgroup/security/download.php/5790/sstc
-saml-core-2.0-draft-07-diff.pdf.

Scott Cantor: concern about language in 3.3.4.1 defining matching and strongly matching. This material 
needs further work, especially around matching subjectconfirmation.

Eve: AuthenticationContext first appears at 876. The concern here is that we have a generic container 
for authentication context, is there a case where we may need to pass-by-value the authentication context?

Rob: concern about nesting and structure of Section 3.4, where should the processing rules be located?

Prateek: Name identifier mapping use-case?

Scott Cantor: ability of a SP to go to an attribute authority based upon retrieval of an alternative name from an identity provider.


2. Eve leads group through the W-28a attribute proposal

Discussion around Section 3.2. 

Do we really need the material on lines 162-167? 

John: Allows a handler to fail gracefully and send an appropriate error message?

Eve: remove 162 to 167, pending any request for their conclusion.

Discussion around lines 191 of the specification - [Scott] should it be modified to exclude SAML attributes?

Eve: Issue around line 137 - there are two different ways that a type can be specified for attributes. 
We are requiring that they "should" be compatible. Is there a way to strengthen or change this?

3. Re-defining artifact as binding

Scott outlines the idea that artifact model could be expressed in bindings as a general mechanism for
implementing request-response pairs over HTTP gets and re-directs. The web browser profile would then
be a much lighter instantiation of the binding.

Scott will pull together a proposal on this topic in this week.

4. Settling the remaining issues around "subjectless" constructs

Eve walks us through her proposal. The proposal is to provide an abstract type that is an ancestor of
the assertion type which would be subject-free. What should this ancestor type and element be called?

Scott: why not make subject optional? We would write processing rules that would require this element to
be always present.

Discussion around whether this would meet the XACML needs. People should comment on this proposal, our
goal is to vote on it next week on the 16th.


5. SSO freshness vs. assertion lifetimes

Scott: questions whether anything more is needed beyond the issue instant in an assertion. Why can't the
SP decide on the relative freshness of the assertion based on issue instant? Suggestion that proponents of
the IdP setting bounds on SSO freshness step up and make a proposal.

7. Should we use differently named <*Response> elements in the case of each protocol, or literally use 
<samlp:Response> each time?

Eve will add to issues list.











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