============================================================================ SSTC/SAML concall Tue Jul 15 08:57:58 PDT 2008

----------------------------------------------------------------------------

AI Summary

----------

AI - Eric Tiffany to document/distrib the "suspect text" from the NIST doc(s) (NIST-800-63 (most current draft) at least)

---------------------------------- Brian Campbell (bc) wrote:

Voting Members: George Fletcher AOL Rob Philpott EMC Corporation Scott Cantor Internet2 Bob Morgan Internet2 Eric Tiffany Liberty Alliance Project Tom Scavo NCSA Jeff Hodges NeuStar, Inc. Frederick Hirsch Nokia Corporation Srinath Godavarthi Nortel Paul Madsen, NTT Ari Kermaier Oracle Corporation Brian Campbell Ping Identity Corporation Anil Saldhana Red Hat Emily Xu Sun Microsystems David Staggs Veterans Health Administration

Members: Duane DeCouteau Veterans Health Administration John Bradley Individual

Quorum Achieved: 15 out of 20 Voting Members

Membership Status Change: Kent Spaulding, Peter Davis and Paul Madsen (Lost Voting Rights)

=JeffH (jh)

bc/jh: punt to next week because last minutes weren't published until this morning.

jh promises to get this week's minutes out in more timely fashion.

bc: haven't seen any feedback on this spec as yet.

bc: some disc on this on list, but from Nate who is not on call today

Tom Scavo (ts): was reviewing draft -03, sent comments to list, but since -04 is only slight update to -03, comments relevant

sc: no fundamental disagreement w/Nate, but there is a question (ques) wrt rules for requesting SubjectConfirmation (SubjConf), there's a ques wrt syntax rules for requiring a HOK assertion -- so there's a ques on whether or not one always needs to pass SubjConf data in a request, and perhaps the same thinking applies to queries

sc: so there's a ques whether this is worthy of an errata, but wondering what TC thinks...

ts: once SC pointed me to the additional text in Profiles [saml-profiles-2.0-os], it was clear, so maybe the text in Core [saml-core-2.0-os] needs to be cleaned up, but don't feel strongly about it, will leave it up to you SC if you think that it needs to be formally cleaned up

sc: ok, will look at it, not sure what I was thinking when orig wrote that text; this is relevant to another profile that I wrote in Liberty [Single SignOn Service (SSOS), ensconced in the "Authn Svc/SSOS/NameMapping" spec], because it actually uses these features -- will endeavor to go back and re-read it, esp to see whether the LAP spec is saying anything contradictory

bc: this spec is out there, want to remind folks to review it

john bradley (jb): did steer infocard steering comm folks towards this, but they haven't gotten to it formally...

RL "Bob" Morgan (rlbob): don't you mean osis?

jb: but all the approp func in osis to review this are now in infocard foundation...

[further discussion on this punted to AI review (below)]

Eric Tiffany (et): waiting for feedback, but may just make own decisions and just put out a new draft will appreciate feedback, though..

et: feels that it is

bc: not sure what the content of a stmt ought to be -- do we even have consensus here wrt what we might say to them?

sc: are they soliciting comments?

et: not sure, believes that feedback would be welcomed

sc: impression that we can say something as a TC if we have agreement as a TC, and then some folks here feel that its reasonable to outlaw bearer, but not SSO per se, others that perhaps at level 4 not doing web sso is reasonable

et: haven't really made clear what it is that they are objecting to, in the doc there certainly are mechs to make assns workable in higher loa contexts

rlbob: not clear what they mean wrt "assertions", reasonable to say that "there's these other uses of saml assns in the world that make sense in this context" but doing that is a lot of work, but in abscence of any "customers" who actually want to make use of that sort of stuff, they prob aren't going to go thru effort to make updates to doc -- this is for govt agencies, not wide world

et: we didn't have disc at LAP Plenary last week, but various govts around world do use NIST docs as templates, and so would be nice to cover the base in case...

rlbob: an alternate sort of resp would be from the TC or intersted parties as sort of a comment on the doc -- we see this doc draws a line btwn bearer assns and classic pki, there's a use of saml that's at least as strong as pki, and so those govts/other parties that want to use saml as a pki replacement up to LOA-4, that works -- but it'd be hard at this point to get NIST to do a full eval of that claim at this point

bc: we could claim wrt saml assn HOK is good for level 4, but...

et: we just need to look at it from our persp and see if can come up with a shrink-wrap response to it, and there's the issue of using saml everywhere else and pki at loa-4 is kinda bogus, so would be worth to address it...

?: maybe an informal comment will allow them to adj doc wrt this

et: an issue is that we don't have a canned profile that makes it easy/clear to alter position

sc: an issue is that this is general doc, not spec, we're viewing it too strictly, so perhaps we can craft language that improves that statment and then federations can say that "what we're doing meets the intent of this nist doc"

can write this up but need help wrt where in NIST doc there's the lang we object to

bc: can et take action to document where the lang at issue is in the nist doc(s)

AI ET to document/distrib the "suspect text" from the NIST doc(s) (800-63 at least)

bc: came up yesterday as protential errata item

there is some lang in core that perhaps is too strict and maybe the result of having only concrete approach to AudienceRestriction (AudRestr), and perhaps we need to ease this language?

sc: couldn't have a protocol that didn't have any rules, and so some rules were written in core that u should do if you don't have (good) reasons not to do them

sec 3.4.1.4 -- if you follow those rules, you have to have an AudRestr that points to the entity that sent the request

the prob is that once you put an aud in, ur telling the relying parties that if they aren't in Aud, they can't use it

thus putting more than one entity in AudRestr is a big change

my suggestion is to read that text in context of text above it -- these rules are to take effect in the abscence of any specific content (eg AuthnRequest)

so if use case is such that need to put something in Request to signal the profile, then that's all you need to do in order to get around that language

suggest tweak the text above it to make clear that "if you know what you're doing, then you can not follow the below" eg "you can follow whatever rules are nec for your profile"

bc: is this necessary for folks writing profiles?

sc: not that big of deal in comparison with other errata working on, but would be good to do, since issue came up thought it should be clarified one way or another

ts: can live with what's there so don't feel strongly about it

sc: don't want AI on this, will leave it on the table for now, might do it, we'll see

[no remarks]

John Bradley (jb): circulated it to OSIS list

feedback on this profile is not in OSIS scope anymore, it should be Info-Card Foundation (aka "Information Card Foundation (ICF)" <http://informationcard.net/> ) providing feedback. OSIS is open to developing interop tests based on a spec.

thus JB also circulated to the ICF general list, and JB has proposed a ICF Working Group to provide some sort of constructive comments on this draft. This was on the agenda at the last ICF board meeting, however time ran out before it was discussed.

everyone [he's talked with about the notion of this spec] "has been really positive"

Microsoft et al, are forming TC at OASIS that will "hold information card IPR" [apparently code for "the ISIP (infocard selector IOP profile) spec will be submitted to this new TC"], first meeting will (likely) be at end of Sep-2008 in London (this apparently hasn't yet been announced OASIS-wide)

this was "secret", but Abbie Barbir said it was now ok to mention it to folks

sc: observes that various specifications have been "left hanging" with microsoft/ibm-driven "ws-" TCs [eg ws-sec, they just shut them down when the work is "done"] thus no on-going maintenance -- thus don't want SAML InfoCard Profile spec to goto this new TC, rather have it stay in SSTC. But, there's a certain vendor not on sstc, want feedback from them (whether via front- or back-channel) wrt the SAML InfoCard Profile spec...

jb: that vendor wants jb to set up ICF workgroup to funnel feedback to the sstc.

so let's keep this AI open for now

closed.

open.

open

closed.

open.

open.

open.

open.