Re: [security-services] Proposed Agenda for SSTC Call (29 June2010)

[Nate Klingenstein <ndk@internet2.edu>]

> 1. Roll Call&  Agenda Review.
>
> 2. Need a volunteer to take minutes.

Nate volunteered to take minutes following a vague threat regarding document and Wiki management issued by Scott.

> 3. Approval of minutes from last meetings:
>
> Minutes from SSTC Call on 15 June 2010:
>    
> http://lists.oasis-open.org/archives/security-services/201006/msg00037.html

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

>    (c) SAML V2.0 Holder-of-Key Web Browser SSO Profile Version 1.0 as a CS
>         - Status: New ballot has been requested.
> http://www.oasis-open.org/apps/org/workgroup/security/email/archives/201006/msg00032.html

The ballot itself has not been created yet and is awaiting action by OASIS.

>    (d)  SAML V2.0 Holder-of-Key Assertion Profile Version 1.0
>         - Status: CS-01 version of this doc is on WiKi.
>         - AI: Thomas to ask Mary to move into Doc tree.
>         - Status: Awaiting Mary.
>
>    (e) Kerberos related items. [Josh/Thomas]
>          - Kerberos Web Browser SSO Profile:
>          - Status: Public review period closed on 15 June 2010.

The public review for Kerberos items closed with no comments received.

Scott was looking at the Kerberos Attribute Profile, which had already gone through public review, and he found two issues.  First, he couldn't find a schema, as there was nothing accompanying the CD.  If there is no schema, then this document can't proceed.  Thomas will look for the schema.

Secondly, Scott has deployers who want to implement this.  We're not sure what the use cases with the APREQ are, but the customer demand that Scott has is for passing actual Kerberos credentials in an attribute, and he doesn't know how that is best done.  In their scenario, the APREQ messages need to be created at the relying party, and it seems reasonable to tackle that by extending this document.  They were asked to send something to the SSTC or another mailing list, but it was just back channel communication.  He would like to revise the attribute profile and include details about how to make that binding.

David asked whether Thomas had thought to use SPNEGO.  The actual Kerberos SSO document assumes HTTP negotiate could be used in the front end when the client is authenticating to the IdP.  The IdP could also be authenticated using other methods, though.  If the IdP knows you, you could re-authenticate the user with a password, but the net effect of getting an APREQ message remains the same.

>    (f) Expressing Identity Assurance profile for SAML2.0 (LOA)
>          - Status: Public review period closed on 13 June 2010.

A large set of comments were received regarding these profiles, and regardless of the status of the document, we're obliged to respond to the comments in some formal way.  Scott will revise the document, which he thinks needs another editing cycle too -- as it's got too much non-normative material that is masquerading as normative material -- and respond formally to the comments as well.  An informal response has been issued, and this was done on the list.

This will take Scott some time, as Paul hasn't been attending and Bob is not available for work efforts now(though Scott will run the changes by him).  InCommon and the Federal Government both intend to use this document, so there's pressure to get this done.  John Bradley thinks he can find some time to help Scott on it.

>    (g) Older docs: Thomas has formally asked Mary to post these 4 docs (3/11th)
>          (I) Protocol Extension for Third-Party Requests (CS-01)
>         (II) Protocol Extension for Requested Authentication Context (CS-01)
>         (III) Shared Credentials Authentication Context Extension and Related Classes (CS-01)
>         (IV) Text-based Challenge/Response (CS-01)
>          - Status: Still awaiting response from Mary.

Still waiting.  Frederick will ask Mary about this later today.

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

Phil sent some new scenario documents, which is a revision of the prior document that had three ways of adding a subject.  A fourth call of "notify method" has been added.

Based on the feedback, Phil started circulating the use cases with customers and organizations.  The general feeling was that a two-step approach was preferable.  They like an approach where the receiver always pulled the data, and want a way for someone who hasn't made a change to initiate a pull for new attributes.

A notify approach struck him as the most natural approach.  This can be both where the SP or the IdP wants to notify the other of a change to the attributes of an identity that is managed in a distributed fashion.

This notification may have bindings that are either front channel or back channel.

In the back channel mode, it could be either an IdP or an SP initiating or receiving any message.  A change notify request is issued rather than a manage subject request, which provides only a subject identifier.  The recipient can act immediately or add it to a queue.  This architecture allows for asynchronous processing.  A simple attribute query about that subject can then be used to grab fresh information.  The recipient then does an add or merge however it sees fit.

The front channel profile is similar, except that an authentication request is used rather than an attribute query.  This gives the recipient the ability to bootstrap credentials using that security context to create a new representation of a user.  This is more of a synchronous call.

The advantages of this modification is that we get new functionality from change notification that doesn't exist with a pure subject modification, and we're using current SAML protocols to transfer data.  It also gets away from distributed subject state management, which is difficult, particularly in a federated context.  There is just one party saying, "I have a change in data," and the other party says, "that's interesting, I'll pull it."  The disadvantage is that it may be seen as a higher cost operation, because there's a second set of transactions to perform an update.  But Phil thinks this is more useful to more parties with this approach.

Scott generally prefers this new model, but he keeps coming back to the SPML question.  He has to believe that a provisioning standard included change notification messages.  At a recent higher ed middleware conference, there was a lot of conversation about provisioning, including the state of SPML.  Scott strongly urged those parties to review Phil's proposals, and to bring their use cases to the SSTC table.  He's concerned about the possibility of duplication, though he gets the hint that the SPML TC is closed right now.  Could using SPML be a vehicle for addressing some of Phil's requirements rather than doing things twice?

In the case of NSN, their issue is more about handling name identifiers, which SPML doesn't really address for reasons that were unclear because Thinh was not present.  A notification within SAML that a change is available allows the parties to use different protocols for the actual transfer of attribute information: step 5 and 6 in his back channel draft could be replaced with SPML, OpenID, or whatever.  But Scott is more curious about the use of SPML to deliver the actual notification message.

Phil will be speaking with one of his SPML experts following this call to see whether SPML can meet these requirements.  There's apparently things missing in SPML that make it "unable to handle SAML."  It might be that SPML is either an example from which can be learned, or something that can be profiled.

It's still unclear how an SP or IdP notifies another party that it's interested in receiving changes; this drifts quickly into publish/subscribe.  The same case could be made for NameID management, which doesn't have a heavyweight process.

Scott's other concern about creating a new protocol is that people immediately want to optimize it and collapse it again, defeating the purpose of creating a new protocol in the first place.  His overall inclination is that this backchannel stuff just screams to him that this is something SPML was supposed to do, and profiling of SPML should be examined to see whether it can meet the needs.

It's the binding of the message to different protocols where Phil thinks you get into trouble, where he doesn't want to see the message strictly strongly bound to a protocol, which could impede some implementations.  For example, Salesforce wants to be able to use this messaging to transport PoCo and vCards.

Hal checked out SPML and couldn't find any sort of reverse channel flow like a notify at all.  Scott isn't surprised, because the notify would be the change itself.  It fits fine with the back channel model.  The part that seems new to him is the attempt to incorporate this flow into the front channel.  But if we're going to do it in SAML, then a back-channel notify message would be much simpler to craft than a new unidirectional provisioning operation.

Anil hasn't seen real adoption of SPML, and Scott wonders whether that's because the missing SAML pieces were never done, or that provisioning is hard, or what.  Anil thinks it's because of the wide variety of subsystems such a provisioning system would need to be integrated into, but it's not clear.

All of our proposals here have been focused on a single principal.  Scott wonders what you do if you have more than one?  Phil thinks the notification can include multiple subjects, but does that lead to querying for each one of them one at a time?  An attribute query requires a singular subject.  If we start going that way, then we're reinventing SPML, and we need to exhume it in order to understand why it hasn't gained traction before we start doing that.

Phil thinks SPML is great for bulk provisioning, but it's much weaker on single changes and synchronization of singular federated relationships.  It may be that the proposal on the table is for single changes and bulk messaging should be done using SPML.  We all want to scope this properly and avoid having one turn into the other.  If we think there's a niche here where SPML is overkill for an operation, then we're in good shape; both Phil and Scott want to find that sweet spot.

Phil will do some investigation into SPML, and Nate and Scott will try to instigate the academic community to do so too.  Scott will circulate some of those names to Phil.  We may try to blackjack a few SPML experts to join the next SSTC call, and if that was successful, we could get the academics to join in that too.

>    (i) SSO initiation draft (Scott) - any updates?

Scott's not ready to take this to public review until there are other documents that can come to review too.

He uploaded a profile a couple weeks ago to expand metadata to allow signing and encryption algorithm negotiation, but he hasn't received much comment on it yet, other than some backchannel thoughts from John, who thinks it's wonderful and that everyone should implement it.  Scott moved to take the first WD forward to CD.  John Bradley seconded, and there were no objections.

http://wiki.oasis-open.org/security/SAML2MetadataAlgSupport

> 5. New work items:
>     - SOA-TEL token correlation document uploaded (Federico)
>         - Please review doc for July 13th SSTC call.
>
> http://www.oasis-open.org/committees/download.php/38374/sstc-saml-token%20correlation-profile-v0.8.pdf

Federico was unable to make this call, so everyone was asked to review this profile in preparation for the next call in 2 weeks.

> 6. Assorted threads on saml-dev/comment list:
>     - IETF Federated Authentication BOF (at July IETF meeting)
>
> 7. Propose an SSTC Face-to-Face meeting for September 2010:
>     - Awaiting for room confirmation.
>
> 8. Next Call: Tuesday 13 July, 2010.