Re: Proposed Agenda for SSTC Conference Call (Tue 21 Sept 2010)

[Nate Klingenstein <ndk@internet2.edu>]

> 2. Need a volunteer to take minutes.

Nate volunteered.  Quorum was achieved.

> 3. Approval of minutes from last meetings:
>
> Minutes from SSTC Call on 7 Sept 2010:
>
> http://www.oasis-open.org/apps/org/workgroup/security/email/archives/201009/msg00016.html

Anil moved to approve the minutes and Scott seconded.  The minutes were 
approved.

>    (c) SAML V2.0 Holder-of-Key Web Browser SSO Profile Version 1.0 as a CS
>        - Status: CS created and publsihed.
>
>    (d) SAML V2.0 Holder-of-Key Assertion Profile Version 1.0
>        - Status: CS created and publsihed.

These have both been created and published.  Nate has not updated the 
Wiki yet, but will do so.

>    (e) Kerberos related items. [Josh/Thomas]
>        - Kerberos Attribute Profile:
>        - AI: Josh/Thomas will suggest additions to Attribute Profile.

The profile is still being retooled alongside the team from CMU who 
provided the additional use case discussed in prior minutes.  The 
revision is probably almost done and an updated version should land in 
the SSTC within the next several weeks.

>    (f) SAML V2.0 Identity Assurance Profiles, Version 1.0
>        - Status: 15-day review closed on 10 Sept.
>        - Any comments received?

Bob and Scott were not aware of any further comments received on the 
Profiles.

Paul attested to the fact that no further comments were received, that 
CD-02 was reaffirmed and unchanged; Scott seconded it.  No objections or 
concerns were raised.  Nate then moved to create a CS ballot for CD-02 
of the Identity Assurance Profiles.  Paul seconded Nate's motion.  
Thomas will submit a request to Mary for the ballot.

>    (g) SAML V2.0 Metadata Profile for Algorithm Support Version 1.0:
>        - Status: now in 60-day public review. (Closes 13 October)
>        - Any updates?

Scott had observed that the examples were broken in this profile, and 
he'll update a new working draft shortly.

>    (h) Service Provider Request Initiation Protocol and Profile Version 1.0
>        - Status: now in 60-day public review. (Closes 13 October)
>        - Any updates?

No updates.

>    (i) NSN Attribute Management proposal (Thinh/Phil) - any updates?

Draft 2 was sent to the list on Monday.

The terminology has been cleaned up so that notify issuer and notify 
target are more explicit.  The references have been updated.  The core 
protocol is largely the same; the major change is that instead of using 
a SAML subject, a SAML NameID/EncryptedID is referenced in the schema 
instead.

Front-channel and back-channel have been renamed to asynchronous and 
synchronous.  The terminology here is meant to match the rest of SAML's 
terminology.  Scott said this was never deeply discussed, and the goal 
was to create profiles that were not specifically tied to bindings.  The 
goal was to keep bindings separate from profiles, and Scott came up with 
arbitrary categories for those bindings.

Scott suggested the examples be moved to the core protocol section.

In retrospect, he's comfortable with the categories, but not so much the 
way it was laid out in this document.  He just wants to see a core 
protocol that is binding-agnostic, and a profile that defines use and 
bindings of the protocol; Thinh agreed with the approach.  Either 
terminology is comfortable for him, and placing both into the same 
document is fine.  A conformance section, which is a requirement to 
conform to OASIS rules, most sensically matches a profile, since 
conformance to a protocol is a less meaningful concept.

The issuer can now state which protocols it is capable of using.  If it 
suggests a non-SAML protocol such as SPML or OpenID to subsequently pass 
the data, omitted is how they would handle the use of different types of 
identifiers.  But Scott observed that SAML does not have a fixed set of 
identifiers; it has a structure to allow you to use any type of 
identifier you would like, and that should suffice to handle this aspect 
of the multi-protocol use case.

Tom Zeller submitted some questions to the list about this tonight 
regarding clarification of the differences between a ManageNameID 
request and a RetireSubject in the Notify protocol.

Frederick was a little confused as to why PoCo was included, since there 
is relatively little protocol included in PoCo.  The idea, put forth by 
Salesforce.com, was that a notification could be sent using 
ChangeNotify.  They wanted to use PoCo as the payload for a large bulk 
transfer, and would "secure the channel and do whatever."  Phil 
expresses no opinion about how this next step is performed, considering 
it out of scope for this proposal.  The same is true for LDAPv3, SPML, 
etc.; the notification is the only part that SAML is responsible for if 
SAML is not the transfer protocol.  It is a purely informative reference 
and does not affect the SAML operations, and as such the references are 
non-normative.

In section 2.5.1, if the Notify Issuer indicates that many protocols are 
available, a question was outstanding whether there should be a way to 
indicate preference, e.g. through another attribute or an ordering of 
the URI's.  The other way to do this would be through the SLA.  Scott 
suggested text indicating that, in the absence of out-of-band 
information, the order in the element SHOULD be taken as preference.

It should be clarified that a response will use one protocol, as the 
alternatives allowing for the use of many protocols to respond to a 
single ChangeNotify were too complicated to countenance.

Scott will look at the schema for the next call.

The next step for Phil will be to complete the profile section and to 
move the examples into the profiles to give a cleaner separation.  
There's a fair number of empty paragraphs left to do.  Detailing how an 
AuthnRequest works with a ChangeNotify, for example, is a goal.  This 
would differentiate between an ordinary AuthnRequest, and the initiation 
of identity federation via presentation of an AuthnRequest.

Thinh proposed another scenario where a ChangeNotify would lead to an 
AuthnRequest that would suggest an identifier that could be used to 
create a new identity at the recipient of the AuthnRequest, followed by 
a ChangeNotify Response.  Phil has some concerns about mixing the 
protocols in such a way.  Given the complaints and problems about 
getting the user-agent to the providers in the right sequence at the 
right time, Scott is dubious that such a mix can be performed well, and 
a consensus was reached that a cleaner separation between the two, 
rather than an encapsulation, would be a better approach.

Scott suggested a Metadata section needs to be added to the document as 
well.

>    (j) SOA-TEL Token Correlation Profile  (Federico/TI) - any updates?

Federico had no updates on the document itself.  He analyzed the 
specification again after Scott's comments regarding the applicability 
of the delegation work to Federico's use case.

Federico is still not sure whether the token correlation requirements 
and semantics are sufficiently different from the delegation work.  He's 
also not sure whether the token correlation profile and syntax are 
complete and correct.

Some of the restrictions have been placed on Federico's company by their 
vendor, due to limitations of the IdP implementation.  It was more 
comfortable sending two separate assertions.  It also more simple for 
them to implement the issuance of SAML assertions that are generally 
usable at a number of services, rather than issuance of specific 
assertions for every application, because the IdP requires less 
knowledge of the business services.  It's also nice to decouple business 
policies from the actual technical implementation.

He's still concerned about the processing of the expiration time of the 
first SAML assertion, and whether and how to imbed the link from the 
second assertion to the first assertion, particularly without 
invalidating the signature on the assertion.  Requiring that both 
assertions be valid makes the profile a little simpler.

Federico also thought it might be interesting to place the correlation 
element out of the assertions themselves, and use it as an entirely 
standalone token.

Federico understands if this profile is not considered the best approach 
within the SSTC on the basis that existing SAML specifications could 
achieve his goals.

Scott sees a subjective question and an objective issue.

Subjectively, he thinks it's inappropriate to create a profile that 
allows an RP to ignore the validity of one of the assertions.  Nate agreed.

The objective issue with regards to this profile is there is no way to 
use the condition that he's trying to create outside of the signed 
content and keep it in the assertion.  If the correlation condition is 
not expressed in the assertion, then it's not in SAML, and needs to be 
done somewhere else, such as WS-Security, where there are already ways 
to chain multiple tokens to a single message, which may be a more 
appropriate foundation.  If you want to recycle elements of SAML in 
another protocol or context, that's fine, but it's still not a SAML issue.

Federico explained that the WS-Security working group is on maintenance 
status, so it's a difficult place to do further work.  As such, Nate 
suggested that Federico try this series of actions:

1)  Analyze the delegation profile to see whether its semantics and 
technical requirements can solve his use case.
2)  If not, make sure that token correlation can be expressed at the 
assertion level, rather than at a message level, or outside the 
assertion.  The SSTC is not the right place for definition of message 
level constructs.
3)  If token correlation can be expressed as a <Condition> in an 
<Assertion>, and the requirement that both <Assertion>s be valid is 
okay, then continuation of work on the Token Correlation Profile in the 
SSTC is appropriate.

>    (k) Channel binding proposal -- Scott.

Scott has been playing around with some strategies for incorporation of 
the channel binding concept for pairing SAML to GSS or SASL.  He's come 
up with a way to allow the IdP to be a mediator for channel binding 
negotiation, a cool little trick that can really improve the phishing 
story.  One very simple application of the material would be to plug a 
MITM hole in the existing SOAP binding, where the SOAP binding is often 
authenticated with the SOAP signature because client TLS is more 
painful.  From the people who have looked at it, some consensus has 
arrived that it could be useful.

He plans to move this along independently, but in parallel, will produce 
a new version of the ECP that uses the channel bindings in this proposal 
and also adds holder-of-key support.  The presentation of the profile 
would also be simplified so it would be less confusing.  This has a ways 
to go, but he wants to move this along fairly quickly, in order to 
encourage a GSS proposal(at the IETF, likely in KITTEN rather than the 
SASL working group) to move more rapidly too.  This will likely lead to 
some natural liaison work with the SSTC.

>    (l)  Metadata extension for Login/Discovery -- Scott.
>

Scott hopes this document will speak for itself, and it has been alluded 
to on a number of other calls.  This is a specific proposal from Sampo, 
he believes, to use the Organization elements in metadata to include 
descriptions of IdP's and SP's and include logos.  Back then, 
individuals thought it distasteful to do it, but based on experience and 
embedded base that have accrued since then, it seems clear that the use 
case is important and some extensions are necessary to address it.

The extensions are in two subsets; one is for user interface, and the 
other set of extensions relates to hinting information to allow 
discovery tools to potentially derive guesses about the IdP to use, 
particularly from client information, such as network address.  Some 
strawman implementations are being fiddled with right now, but the 
standards process doesn't need to be rushed.