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: Re: [security-services] sstc/saml concall minutes Tue 2-Dec-2008 (withattendance)


Jeff, I just wanted to thank you for picking up the note-taking task  
so often.  I promise I'll be more forthcoming with offers in future,  
and I hope others consider doing so as well.

	Eve

On Dec 2, 2008, at 4:14 PM, =JeffH wrote:

> comments to the list please.
>
> =JeffH
>
>
> = 
> = 
> = 
> = 
> = 
> = 
> ======================================================================
> 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.
>
>
> -----------------
> Attendance:
>
>
> 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
>
> Members
> ---------------------
> Peter Davis, Neustar
> Rob Philpott, EMC
>
> Observers
> ----------------
> 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
> call
>    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
>
> discussion...
>
> 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
> spec
> 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 --
> this
>    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
> error
>  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
> anyway
>
>  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",
> modulo
>  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
> wants)...
>
> 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
> for
>   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
> originally
>   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
> easy
>    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
> time,
>    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
> attributes
>  to an <md:EntityDescriptor> or <md:EntitiesDescriptor> element, to
> communicate
>  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
> signature
>  over metadata, there is a sense in our community that folks will do  
> it non
> interoperably
>
>  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
> prof
>    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?
> http://www.oasis-open.org/committees/download.php/29921/xspa-saml-profile-cd-01
> .doc
>
> 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
> review.
>
> hl: 2nds
>
> discussion...
>
> 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
> allow
>    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
> where
>   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.
> HITSP
>
> 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 --
> hopefully
>    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
> want
>   to make a stmt about in the future -- coming up on part of cardspace
> deployers
>
> bc: if anyone has bkgrnd/time to look into this, please do so.
>
>
>> 4. Other business
>
> none.
>
>> 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
>
> = 
> = 
> = 
> = 
> = 
> = 
> ======================================================================
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>

Eve Maler                                         +1 425 947 4522
Principal Engineer                            eve.maler @ sun.com
Business Alliances group                    Sun Microsystems, Inc.



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