[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Minutes of Focus subgroup 25-Sep-2001 concall
Minutes of Focus subgroup 25-Sep-2001 concall Participants: JeffH Joe P. Marlena E. Simon G. Scott C. Phill HB Irving R. Chris M. Darren P. Carlisle A. Hal L. Alan (of authentica) Don F. Tim M. > ACTION items > ============ > > ACTION: Prateek to start traceability review before the next TC telecon using > discussion-01 docs and going back to use > cases" (previous disposition: wait state) Prateek not on call. Action Item (AI) remains open in wait state. > ------ > ACTION: Jeff to send to the list Eve's proposed bibliography section > for document guidelines with his comments. done. > ------ > ACTION: Marlena to champion DS-1-02, Anonymity Technique - status after > discussion thread of 20-aug? some debate still within shibb. Shibb folk are going to discuss it again this aft. have decided to not put forth their own web browser profile. don't try to ident user by name. so in authn assn want to pass a handle the RP can use to get an attr assn, so how do we put a handle in the authn assn? thinking about adding another choice to subject, some thinking about making use of subj name. they're still debating this. [this was further discussed below in the Open Discussion section] AI still open. (tho Marlena expressed during open discussion below that she may not wish to pursue this further). > ------ > ACTION: Prateek to champion ValidityDependsUpon [21-Aug: Prateek will > send out message within the next week to close out issue but call out > questions.] AI done. Prateek sent note to list mon 24-Sep. issue DS-3-03 closed? > ------ > ACTION: Jeff to champion DS-4-02, XML Terminology, aka Messages and > Packaging. done. > ------ > ACTION: Krishna to drive SAML profile of xmldsig. > [has sent msg to the list soliciting input.. > http://lists.oasis-open.org/archives/security-services/200109/msg00046.html > ] in progress. > ------ > ACTION: Bob B & Marlena: <Subject> in Core doc to correspond to Artifact. > [status msg to list slated for Mon 24-Sep] haven't had discussion with BobB yet. Will try to connect over the next week. > ------ > ACTION: Bob B: Return of not current valid assertions to RP (e.g. post > dated) > [text in Bob's powerpoint, and in e-mail to the list. Done. See.. > http://lists.oasis-open.org/archives/security-services/200109/msg00041.html > ] done. > ------ > ACTION: JeffH to transfer sec consideration work to Chris [in progress]. in progress. > ------ > ACTION: Don: Smart client profile - develop a proposal. [to be sent out to list > by Mon 24-Sep] in progress. will do by fri 28-Sep. > ------ > ACTION: Don: to elaborate the number of 1-1 relationships and propose how > to fix the resulting scaling issues. [to be sent out to list by Mon 24-Sep] same as above item. > ------ > ACTION: Gil: [DS-6-01:Nested Attributes] Not sure how SAML could address > this [revisit at next call] in progress, gil in hiatus. > ------ > ACTION: Prateek: To make a proposal on the mandatory use of HTTPS [was Gil's; > Report back by Fri 28-Sep] in progress. Irving discussed with Prateek last week, they're thinking of some new language along the lines of "Mandatory to impl, but not to deploy" Hal noted that the contentious issue is in the context of conformance. > ------ > ACTION: Hal & Bob B: Artifacts are bearer instruments, Assertions are not. > [Done/closed. See.. > http://lists.oasis-open.org/archives/security-services/200109/msg00041.html > ] > done. > ------ > ACTION: Hal: to write scenarios (and / or provide definitions) for how > NameIdentifier is used (e.g., when it is in SubjectConfirmation to identify > an assertion vs. when it is used to represent the assertion referent) > [done. See.. > http://lists.oasis-open.org/archives/security-services/200109/msg00041.html > ] done. > ------ > ACTION: Irving: Multiple NameIdentifiers are dangerous - Irving to write > up proposal. in progress. will shoot for 28-Sep Fri. > ------ > ACTION: Irving: to investigate and write up WAP limits > [done. see.. > http://lists.oasis-open.org/archives/security-services/200109/msg00040.html > ] done. > ------ > ACTION: Jeff: threat model discussions to be removed from the bindings > doc - but rationale preserved somewhere in SAML documents. [Will handoff to > Chris as part of sec consider work; Prateek to be consulted. This item should be > closed.] There was some discussion that separating out sec considerations stuff (specifically threat model discussions) across mult docs will be hard/inappropriate. JeffH noted that to do so or not do so should be explicitly addressed in the context of the overall sec consider work, which is being migrated over to Chris, and that this particular AI should be closed. no objections. > ------ > ACTION: Marlena: SHIB desires 00-02 artifact type (anonymous user & > attribute assertions - non personal identifiable info) core design issue. > [ Marlena reconsidering need for this. status?] shibb will use posted authn assns rather than their own artifact type. Marlena recommends closing this item. no objections. > ------ > ACTION: Marlena: to write a proposal to create another Web Browser > profile that retrieves an Attribute Assertion rather than an Authentication > Assertion. > [ Marlena reconsidering need for this. status?] Shibb isn't going to do this. Marlena recommends closing this item. no objections. > ------ > ACTION: Marlena: to write up use of artifacts for queries > [from 18-Sep call: Query handle in request for assertion - anonymous subject > discussion will resolve this. Status?] Several folks note that it is in -16 schemas, and therefore should just be closed. closed. > ------ > ACTION: Phill: Will produce a core-16 that just contains the notational and > twiddles before any major changes to schema and protocols. > [from 18-Sep call: processing comments from eve, looking at choice groups. end > of week next. 28-Sep] nothing's happened on the document yet. has been experimenting with other specs that would use extension mechanism. JeffH asserts that published spec & schema are out-of-sync, Scott concurs. Phill to re-issue sync'd schema & spec by 28-Sep. > ------ > ACTION: Prateek: "Security properties of Assertion Handle" (Bob Blakley > to act as reviewer). > [from 18-Sep call: One more cycle through bindings con-call - at least through > mid next week. Bob - may linger in review process] in progress. > ------ > ACTION: Prateek: Lookup by artifact: Agreed that he should submit a > detailed proposal to the Core outlining specific changes to specific > sections. Includes new request-response protocol not currently defined in > HTTP binding. > [from 18-Sep call: In part addressed in core-16. status by 9/20?] Tim notes that he took an action to start a thread to pull together the various threads touching upon this topic. Tim sent msg to bindings list addressing this in-part. Hoping to tie this up by next bindings concall. will discuss on that call and report back to the SSTC (by SSTC/Focus concall of 2-Oct?) in progress. > ------ > ACTION: Prateek: Oracle attacks WRT SOAP Profile > [from 18-Sep call: BobB to send references to the list by 21-Sep. Status?] in progress. no BobB or Prateek on call. > ------ > ACTION: Prateek: Push profile / use case to be dropped from document > (Paul Leach's claim that this would assist SAML/Kerberos integration was > never developed - Paul to present this case if he wishes to re-instate this > profile) > out for now". Drop from Actions list?] done. > ------ > ACTION: Prateek: Should the Bindings Group select either the HTTP or SOAP > protocol bindings for inclusion in the final spec? > [from 18-Sep call: open - reasons for inclusion of both profiles or elimination > of 1 should be sent to the list (by 9/25)] no msgs sent to lists yet. Tim'll request that Prateek include this topic on the next bindings concall agenda. > ------ > ACTION: Prateek: Should the SOAP binding address the issue of > intermediaries - generate proposal for how > [from 18-Sep call: SOAP Bindings will include discussion of intermediary, but > need to discuss during Focus portion (wasn't discussed on 9/18)] in progress. Tim speculating that P may have delegated this to Krishna. > ------ > ACTION: Prateek]: This is an editorial issue about the names of profiles. > Prateek to revise current document. > [from 18-Sep call: single sign on terminology to be included in next version. > Status?] pass. in progress. > > ------ > ACTION: Simon: write a concrete proposal that outlines the change to the > nature of the authorization query. done. > ------ > ACTION: Tim: First Contact - will write up what can be done with the > current design. > [from 18-Sep call:to be included in next rev (-06) of bindings doc] done. > ------ > ACTION: prateek: pseudonym or somewhat anonymous subject identifiers in progress. > =============== > Open discussion > =============== > > 1. Call for items to discuss during this time. added to the list were.. Marlena's identifier discussion simon's authz query refinement proposal > 2. Suggested topics.. > > 2.1. Is there a concise consensus decision we can articulate for the > "Substitution Groups Reconsidered" thread, and do we need such? This msg starts > off the thread.. > http://lists.oasis-open.org/archives/security-services/200109/msg00028.html > > Eve's msg here seems to conclude it.. > http://lists.oasis-open.org/archives/security-services/200109/msg00038.html > > I interpret this portion of Eve's msg.. > > > the TC apparently agreed that substitution > > groups are important in extension schemas because if you're extending a > > "null assertion statement" (the head of the chain of assertion types, which > > has nothing particular specified in it), xsi:type gives you no more > > information than a substituted element would. > > ..as effectively saying "we won't use 'block' in the SAML schema." Is that a > correct concise summary? Hal lobbies for removal of substitution groups (subst groups) from the SAML schemas themselves, as long this doesn't preclude use of subst groups can be used in extension schemas. Hal notes the lack of tool support may make use of subst groups problematic in any case. Phill asserts that there are needs in the saml schema itself for which subst groups are well-suited, and if we're not going to use them we need to figure out how to satisfy those needs in another way. NEW ACTION: phill to investigate, report back with recommendation(s) & rationale wrt using substitution groups with the SAML schemas themselves. Related, but tangential, is the decision that we won't use "block" in the SAML schema. Irving notes that reason we were investigating using "block" is that we were trying to come up with a model where we could control the models of extension schemas and thus perhaps more ensure such models are workable. Phill (if IIRC, ed.) argued against using "block" at all. (it's not clear to JeffH whether we have clearly articulated this issue. There's this item in SSTC-F2F-4-Minutes-00.txt.. [ISSUE - Phil] We need to add an issue that deals with blocking the substitution of various core SAML elements. [resolved schema core-16] ..which may mean that we need to open a specific issue on this in the issues doc, and that parenthetically may be saying core-16 will address it. ) > 2.2 Attribute scoping (Scott Cantor). see.. > http://lists.oasis-open.org/archives/security-services/200109/msg00047.html the way to proceed on the above is to write up a proposal encompassing both schema and specification additions/changes. NEW ACTION: Scott to write up a specific proposal for addressing "scoping of attribute values". ----------------------------------------- Marlena's anonymous identifier discussion ----------------------------------------- context: Shibb is discussing this on a call this afternoon. Marlena wishes to provide SAML folk pespective in that discussion. Marlena: disambiguation is the issue from Marlena's perspective. if we use "name" for a query, might be ambig (?). issue also arises with audiences. does RP know what to do? via some outofband agreement? shibb been discussing having a sep sub element, or "just use name" w/o a qualifier. she's asking for saml opinions to take to the shibb discussion this afternoon. marlena/scott: the issue is whether the name carries a qualifier that gives a hint about the semantic properties of the name, e.g. persistence. Irving: is thinking conveying it in-band isn't particularly useful. concerned about additional complexity to SAML schema. marlena: this is the anon case for web browser profile. if we just use a name w/o qualifiers/hints, the rp doesn't know if it is receiving a anon name. scott: if saml wants to support tru anon rather than pseudo, then will def need the extra info. Hal: thinks this is a "blinded subj". it isn't anonym or pseudonym. irving: aspect of this is whether the id used is persistent or not. He doesn't need that level of detail in identifiers. scott: shibb doesn't need that level of detail. Summmary: the message from saml folk that Marlena/Scott will relay to shibb folk is that it is the opinion of the saml folk that spoke up that a RP doesn't need to have hints about whether a subject name may be "blinded" or a "pseudonym" or whatever. ------------------------------ scott: questions/quibbles.. ----------------------------- 1. ip address - is that ip addr of client or of authority? Hal: ~thinks~ it is client, but latest core doc seems to muddy this. 4. offhand answer is "issuer" 2. <didn't capture anything coherent on this> --------------------------------- > 2.3 Relying party tailors assertion in browser artifact profile (Tim Moses). > See.. > http://lists.oasis-open.org/archives/security-bindings/200109/msg00018.html above item to be discussed in bindings discussions. -------------------------------------------- punt to next week's focus group discussion.. simon's authz query refinement proposal > --- > end > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC