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: draft minutes SSTC/SAML concall Tue 9-Sep-2008 [lacks attendance]



============================================================================
SSTC/SAML concall Tue Sep  9   09:00 PDT 2008
----------------------------------------------------------------------------

AI Summary: no explicit AIs issued this meeting.

Attendance: [to be supplied]

Hal Lockhart (hl) presided.

> Need a volunteer to take minutes

Jeff Hodges (jh) volunteers.


> 1. Approve minutes from August 26, 2008
> http://lists.oasis-open.org/archives/security-services/200808/msg00090.html

hl: prior minutes approved by unanimous consent

hl: anything to add to agenda ?

dave staggs (ds): please add XSPA profile discussion to agenda

hl: will do at end



> 2. Document Status
> 
> 2.1 Subject-based Profiles for SAML V1.1 Assertions
> http://wiki.oasis-open.org/security/SamlSubjectProfiles
>
> Voted to request CS vote of revised document - ready as of Sep 7
> http://lists.oasis-open.org/archives/security-services/200809/msg00013.html
>
> Action deferred pending resolution of reference to XML Signature (Second Edition).
> http://lists.oasis-open.org/archives/security-services/200809/msg00014.html


hl: got comment on the doc at 11th hour -- ought to ref xmldsig 2nd ed. 

ways to handle...

1. don't do change

2. can vote to cd if we agree to do the change (it's editorial?), then do 
change, then goto CS vote w/o another pub review

3. made changes, redo pub review, then do CS vote


scott cantor: what's being raised?

hl: there's a footnote ref to the spec, and where that spec is actually used 
is on ref'g the namespace in pg 6, that's it

sc: mebbe we shoudn't deal with it because the namespaces are the same in both 
xmldsig specs

fredrick hirsch (fh): just refer to 2nd edition -- because there's an 
additional required alg in the 2nd edition -- be good for readers

hl: change xmlsig to xmlsig1 ....

sc: if i was editor I'd say this was a waste of time

jh: concurs

sc: there's no ambiguity... [tom scavo(ts) concurs]
this spec doesn't use xmldsig actually
xmldsig shows up in examples only, arguably it should be ref'd in 
non-normative refs rather than footnote
and.. we have five other specs where it is normative and we are going to 
update them formally


hl: resolution is we are going to continue with what we agreed to in last 
meeting, and so chairs are going to req CS vote on this spec, and folks can 
expect that in next week or so.



> 2.2 SAML V2.0 Metadata Interoperability Profile
> http://wiki.oasis-open.org/security/SAML2MetadataIOP
> Draft 2 posted
> http://lists.oasis-open.org/archives/security-services/200809/msg00003.html

sc: went through this spec and made updates wrt comments (many by TS)
probably some examples that can still be put in, but wanted to get text 
updated first
changes should match 

added placeholder for defining x509cert element in keyinfo but value syntax 
isn't defined and so believe that that is errata for xmldsig spec...

I am participating in the w3c xmlsec working group as invited expert and will 
perhaps raise it there

I assume everyone puts a DER-encoded cert value in there, but it should be 
nailed down, because it could be some other encoding, and it prob should be 
nailed down in xmldsig spec(s)...


hl: other approach would be to put a type field in cuz they do sometimes come 
in diff formats, and so (agree) that it isn't inherently obvious which format 
to use...

sc: so put placeholder in the draft to accomodate this...

fh: agree that xmlsec wg should look at this, what's timing?

sc/hl: we've been living with the xmldsig spec as it is for a long time, so 
this is not really urgent

sc: can finess this in our spec, i have placeholder, etc

hl: so, (to pop the stack) -- folks should comment on the spec overall on the 
list so we can move this forward...



> 2.3 SAML V2.0 Holder-of-Key Assertion Profile
> http://wiki.oasis-open.org/security/SAMLHoKSubjectConfirmation
> Draft 3 posted.
> http://lists.oasis-open.org/archives/security-services/200809/msg00008.html

tom scavo (ts): quite a few changes made in this draft
five issues were addressed, summarized in this message...

  Re: issues with sstc-saml2-holder-of-key-draft-02
  http://lists.oasis-open.org/archives/security-services/200809/msg00017.html

at least four of five adequately addressed, one of them, processing the x509 
cert element, needs to be discussed

would like to know how folks are doing it now, way I have it now seems 
reasonable, not sure where other suggestion is coming from...

sc: it is not operationally simpler, but it is (seems) to be simpler impl-wise

I don't want to create spurious failure conditions when xaction should 
succeed. so by doing key comparisons rather than cert comparisons whenever 
possible, it maximizes operational utility [without compromising security]

ts: if you want to do that, should use other element x509ski...

sc: that value is a hash, what i'm reducing it to is key value, haven't seen 
anyone use x509ski, haven't seen any support of it in reality, so am leery of 
using it

ts: it seems your suggestion violates the spirit of xmldsig, which has two 
elements, one for cert another for key...

sc: it's correct imho cuz xmldsig spec doesn't firmly spec the op semantics

hl: tends to agree

sc: keyvalue is problematic otherwise would use it
focus for me is sec of xaction, and writing processing rules that won't 
compromise that


hl: other comments, others familiar with impls?  <silence>

how to resolve?

sc: I don't have prob with profile, as long as processing rules are clear, am 
a little leery of skewed processing rules; operationally speaking since 
assertions are shortlived, am inclind to believe that the op issue I run into 
wrt metadata aren't as applicable here -- my principle objection prob isn't a 
big deal in this context. would prefer it to be the other way, but that's just 
me speaking as an implementer

ts: let's leave this discussion open on the list and see what others think, I 
don't feel terribly strongly about it, could go other way, if this is hangup 
to spec progressing might let it slide, will do some wider research [beyond 
sstc] and see what folks think

sc: will do more thorough review...but in skimming, see some things like 
SubjectName procesisng, prob need to say more concrete things about how PKI is 
wired in, etc...

hl: ok,  folks should read and take comments to list


> 3.  Discussion Threads
> 
> 3.1 Non-browser HTTP binding for SAML  
> http://lists.oasis-open.org/archives/security-services/200808/msg00082.html

hl: any work items that will come out of this? status?

geo fletcher (gf): didn't seem there was  much interest from community, just 
scott & me...

sc: have interest in gen area, doubt is a saml binding, is really an http 
issue, almost a "saml token profile" for REST -- see that as the use case 
rather than casting it as a SAML binding

eve maler (em): have been talking in Sun, put that way, is more true

gf: summarize: sec msgs within http msgs, so why not OAuth?

sc: understand OAuth does some signing, so u might be right..

gf: can use OAuth to pass saml msgs, so mebbe heading in that direction in a 
more general sense...

em: have been talking with various folks circling around this topic, let's 
chat offline...

gf: ok


> 3.2 Attestations from Internet2  
> http://lists.oasis-open.org/archives/security-services/200808/msg00089.html

hl: anyone who has posted an attestation for something in the process, might 
need to update the attestation to spec which conformance clause one is 
attesting to -- please

eg, see what ScottC did, it isn't onerous, please follow suit if 
appropriate/applicable



> 3.3 compatibility of HoK profiles  
> http://lists.oasis-open.org/archives/security-services/200809/msg00000.html

Nate Klingenstein (nk): have had back channel conversation, figured out way 
forward, involves x509 and [?], still haven't figured out metadata stuff; Tom 
also commented that hack to figure out which profile to use isn't general 
enough, agree, not sure how to take forward

ts: will read and reply, agree metadata messy, if you piggyback on assertion 
profile, attach some data in request, have tried to do it, it is difficult 
because subject elements appear in lots of reqs for diff purposes, so would be 
great if you addressed that issue in your profile

nk: no intention to address it, because of impl concerns

ts: so if you attach this meaning to subjconf in request, then IDP would be 
reqired to honor it, if it isn't there, then default would be x509 cert option 
-- would that work?

nk: that's fine except for the idp-first use case, we can hack it specificlly 
in this case, but such an approach isn't general, hence leery.

ts: so the assertion profile mandates x509 

hl: so sounds like resolution is to be more explicit in next draft?

nk: would rather rely on assertion profile spec for this...

ts: can't cuz have taken everything like that out due to SC's req...
that's what meant when said it is difficult 
could write a [shim] profile to address it... (ugh)

nk: ugh

hl: please take further discussion to the list


> 3.4 comments re sstc-saml-holder-of-key-browser-sso-draft-06  
> http://lists.oasis-open.org/archives/security-services/200809/msg00001.html

hl: ts has 2 msgs with comments on the doc

ts: nothing further to say -- it's in email



> 3.5 [added agenda item] Dave Skaggs -- XSPA Profile

ds: am at hipspi [?] financial conf right now, talking about our profiles here

will update the profile, cut back some of the HIMS/health specific stuff in 
it, and want to turn the doc into a tangible committee draft

i.e. have this done by the 2009 meeting, can feature it there, have demo, etc, 
it'll be a big deal

XSPA TC will be meeting this friday, want to firm up the portion thats talking 
about SAML

want to turn it into a committee draft (CD)

have folks read it? do you have feedback?

hl: two docs?

ds: saml xacml profile is in SSTC, will be combined with another spec that's 
in the XSPA TC

hl: it just takes a vote of the TC to make it a CD

?: turning into a lightweight profile for 
Dewyane Ducuto

hl: is it in docs repository in Kavi?

DD: yes

hl: CD is a low bar, i.e. no one on TC is actually objecting to it as it 
stands, but want folks to have notice and time to review, so if you can get 
doc out this week maybe we can goto CD during an upcoming TC concall/meeting

ts: don't see doc in kavi...

dd: in kavi in June...

hl: checking for it in personal archive....

jh: have xspa-saml-profile2008428_V31.doc from April in local cache

dd: that's old...

hl: so if you're publishing in next few days, put it in the "A.5: Post-V2.0 
Working Documents" section of the doc repository, ask for review on the list 
and modulo discussion we can have a vote at the appropriate next TC meeting 
and make it a CD

ds/dd: ok, will do



> 4. Other business
> 
> 
> 5. Action Items (Report created 08 September 2008 10:27pm EDT)
>  
> #0328: Revise SimpleSign
> Owner: Jeff Hodges
> Status: Open
> Assigned: 2008-05-19
> Due: ---

underway, still open


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

open

> #0333: Publish a new revision of Profile for Use of DisplayName in OASIS template
> Owner: Sampo Kellomki
> Status: Open
> Assigned: 2008-05-19
> Due: ---

open

> #0341: Draft text for SSTC submission to NIST
> Owner:
> Status: Open
> Assigned: 2008-08-26
> Due: ---

hl: no owner?

brian campbel: I believe this should be eric tiffany, will fix the action item



============================================================================




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