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: sstc/saml concall minutes Tue 2-Dec-2008 (with attendance)

comments to the list please.


SSTC/SAML concall  Tue Dec 2  09:03:19 PDT 2008

co-chair Brian Campbell (bc) presiding

Motions passed:

Resolved: PE74 is approved errata item now

Resolved: place xspa-saml-profile-cd-01 into 60-day public review.

Action Item Summary:

* AI: Duane DeCouteau (dd): will take AI to do packaging of 
     xspa-saml-profile-cd-01 for public review

* AI: SSTC co-chairs will notify TC admin once receive spec pkg from Duane.


Voting Members
George Fletcher  AOL
John Bradley Individual
Jeff Hodges Individual
Scott Cantor Internet2
Nathan Klingenstein Internet2
Bob Morgan Internet2  
Tom Scavo NCSA
Frederick Hirsch Nokia Corporation
Srinath Godavarthi Nortel
Hal Lockhart Oracle Corporation
Brian Campbell Ping Identity Corporation
Anil Saldhana Red Hat
Eve Maler Sun Microsystems
Emily Xu Sun Microsystems
Duane DeCouteau Veterans Health Administration
David Staggs Veterans Health Administration

Peter Davis, Neustar
Rob Philpott, EMC

Greg Parsons Jericho Systems Corporation

Quorum:  16 out of 20 voting members (80%)

Membership Status:  Ari Kermaier (Oracle) lost voting status.

detailed minutes:

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

=JeffH (jh) volunteers

> 1. Minutes from SSTC/SAML conference call November 18, 2008
> http://lists.oasis-open.org/archives/security-services/200812/msg00000.html

bc: the minutes were just posted to the mailing list so we'll wait until next 
    to approve them. 

> 2. Document Status
> 2.1 SAML 2.0 Errata draft 45/46 -> PE73, PE74, PE75, PE76, PE77 / PE78 added
> http://lists.oasis-open.org/archives/security-services/200811/msg00071.html

Scott Cantor (sc): am making motion to accept PE74 as proposed in errata 46

fh: 2nds the motion


Rob Philpott (rp): xmldsig is also mentioned/ref conformance doc...
bc/sc: that's covered
rp: ok, as long as this updated spec doesn't change anything in conformance 
sc: all algs & references are not changed
    do we norm ref the canonicalization specs?
    <exclusive c14n is referenced>

rp: we say SHOULD use excl but don't say anthing about other c14n approach
    ok, looks good to me, don't see need to postpone

bc: back to motion, any obj to unan consent of approving PE74 ?  
    none, motion passes.
Resolved: PE74 is approved errata item now

bc: moving on to PE75..

rp: the text shd be more specific with respect to 2nd level error codes

sc: 2nd level codes aren't something needing to be nailed down interop-wise -- 
    is a abstract situation

rp: but there's various reasons subject may not match...

sc: it doesn't seem to be worth the amount of work it'd take to do it

tom scavo(ts): don't feel strongly, what sc has in the errata currently is fine

rp: are we going to allow implementors/deployers to stick in other 2nd level 
  code values?

sc/bc: yes

sc: this is a really abstract error condition, this is more discussion than 
    wanted to have, shd take this to the list not sugg we vote PE75 in today 

  pe76 -- wrt validity attrs, suggesting additional txt on that
       folks shd read that one and see if you all agree

  pe77 -- wrt adoption of saml assertions in ws-fed context -- but we can 
         make some constrained changes that would address the prob
     e.g. if we remove word "saml" in various places it fixes it all it seems

  pe78 -- want to discuss this...

  persistent nameid format -- whether or not by definition if those ids can be 
  reassigned to other principals -- applicable in federation use cases
  imho in no situation reassign opaque ids to other principals, i.e. "must not"
  be done so suggest either "must not" or "should not", favors "must not", 
  what others think

Eve Maler (em): this is a bit of a stretch for an erratum
  is there some usefulness in reassign opaq ids?

sc: absolutely not

em: totally breaks the traceablility of ids (which might be what someone 

sc; these are explicitly persistent ids not transient

em: oh, ok, but not sure we should do this at this point

ts: am bit surprised this is coming up as erratum, like eve, 
   there is something btwn "shd not" and "must not" eg "must not be reassigned 
   a year"....

jh: dont think this is good idea

[ detailed discussion ensued with rp equating persist ident reassignment with 
notions of opaque identifier randomness, jh noting that those are seperate 
notions, others chiming in ]

sc: in anycase these proposed changes are simple

   always thought it is a "must not" 

    came up in Shib context via Tom (ts), then realized the saml spec doesn't 
say anything

   don't know of any reasons to reasign persist idents, my intent (when 
   writing that language in the spec) is that it is a "must not", don't 
believe it
   is material change to make it that, but am fine with "should not"

bc: this is something that was intended but isn't really clear, a "shd not" is 
    and nice but a "must not" might affect various impls/deployments

    in any case we shd take this to the list...

sc: am not aware of any errata items that are not in the errata doc at this 
    so if folks know of any they need to speak up.

> 2.2 SAML V2.0 Metadata Extension for Entity Attributes (draft 2)
> http://lists.oasis-open.org/archives/security-services/200811/msg00079.html

sc: wrt attaching tagging info to entities that they admit into a federation, 
have done some draft work on this notion, but now am proposing a formalization 
of it

[from draft spec abstract:
  This profile defines an extension element for use in attaching SAML 
  to an <md:EntityDescriptor> or <md:EntitiesDescriptor> element, to 
  an arbitrary set of additional information about an entity in its metadata. ]

bc: am confused about details

sc: orig proposal is wrt saml attributes, they aren't self-describing wrt 
  over metadata, there is a sense in our community that folks will do it non 

  if asking "why not use assertions?" -- that's hard

  did try to come up with assn profile that's constrained but it's difficult, 
see the
  draft spec.

bc: is there a way to take the attr part out and simplify assn portion so it 
   meets your needs?

sc: don't know. if you take the attr fork out, you don't make it easier to 
impl, the
    assn part is hard to impl -- if there's enuff interest in this to make > 1 
    of it, am happy to discuss/investigate. 

bc: let's take discussion to the list

> 2.3 SAMLv2.0 HTTP POST ≥SimpleSign≤ Binding
> http://lists.oasis-open.org/archives/security-services/200812/msg00005.html

jh: summarizes the delta between this draft spec and the present Committee 
Spec (CS) edition.

[discuss whether want to update the CS version, jh: that's the intention]

[discuss wrt pub review. HL notes there's an escape clause to allow for 15-day 
pub review.]

ts: did a diff on the docs, will send to jh

bc: we will endeavor to vote to pub rev next call

> 2.4 XSPA Profile of SAML for Healthcare
> To public review?

ds: HITSP/HIMSS folks have noted to ds that they'd like to see public
   review of this profile before the HIMSS demo in Apr

ds: moves that we take the xspa profile from cd and take it to 60day pub 

hl: 2nds


hl: what's the rel of the xspa profile(s) to other stds ?

ds: there's 2 -- one for international, another for US realm

    the US realm one is more specific as to the use of certain vocabs that 
    interop btwn health care entities

    there's another profile that's xacml-based

    haven't gotten feed back on ws-trust profile from ws-sx TC

hl: does the overall one ref the other ones (3 of them?) ?

ds: the overall one refs the underlying one

   to know whole story need all 4 docs

   ws-trust and xacml are optional

   saml profile is really required one

   "overall one" -- is in xspa tc and hasn't been publicly released yet

   need to join xspa tc to see docs, encourage folks to do so

bc: does it make sense for sstc to be doing this considering that there is a 
   xspa tc?

ds: guidance from jamie clark et al was that the saml profile should be done 
   there is saml expertise

bc: back to motion, any further discuss?  (none)

bc: any obj to unanimous consent to moving 
  profile to initial 60 day pub review? hearing none, motion passes.

Resolved: place xspa-saml-profile-cd-01 into 60-day public review.

  need AIs to ensure pkg is prepared and send it off to TC admins.

AI: Duane DeCouteau (dd): will take AI to do packaging of 
     xspa-saml-profile-cd-01 for public review

ds: they will state other orgs that shud be notified of this pub rev, e.g. 

AI bc: co-chairs will take AI to notify TC admin once receive pkg

> 3.  Discussion Threads
> 3.1 Comments on HoK Web Browser & Assertion Profiles
> http://lists.oasis-open.org/archives/security-services-comment/200811/mailli
> st.html

bc: seems to be on-going disc on this, do we need broader disc?

Nate Klingenstein (nk): will incorp feedback into another rev of the spec -- 
    in next 3/4 days will be draft -11

ts: will take a pass on it once it arrives

> 3.2 New SAML profiles for XRI
> http://lists.oasis-open.org/archives/security-services/200811/msg00056.html

bc: re-remind folks about these. 

Peter Davis (pd): is info heads-up. are going to be worked on in XRI tc. 

> 3.3 XAdES support in SAML?
> http://lists.oasis-open.org/archives/security-services/200811/msg00074.html

bc: msg scott sent a bit ago, no responses

sc: it came up in IMI tc (icard) -- it may come up as an issues that sstc may 
   to make a stmt about in the future -- coming up on part of cardspace 

bc: if anyone has bkgrnd/time to look into this, please do so.

> 4. Other business


> 5. Action Items (Report created 01 December 2008 01:05pm EST)
> #0333: Publish a new revision of Profile for Use of DisplayName in OASIS
> template
> Owner: Sampo Kellomki
> Status: Open
> Assigned: 2008-05-19
> Due: ---

remains open

> #0332: Revise Query Extension for SAML AuthnReq
> Owner: Sampo Kellomki
> Status: Open
> Assigned: 2008-05-19
> Due: ---

remains open


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