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] | [Elist Home]


Subject: [security-services] Minutes for SSTC Focus Group, Tuesday Oct 16


Minutes for SSTC Focus Group, Tuesday Oct 16
Dial in info: +1 334 262 0740 #856956
Minutes taken by Steve Anderson

>> Focus subgroup Agenda
>>
>> 1 - Agenda review (discussion items after Action Items review)
>>

- Issue addition by Irving: single/multiple assertion question
- Issue addition by Prateek: senderVouches security model

>> ============
>> ACTION items
>> ============
>>
>> ACTION: Prateek to start traceability review before the next TC
>> telecon using discussion-01 docs and going back to use cases"
>>
>> Status: Action Item (AI) remains open in wait state.
>>

- Prateek: once we’ve met at F2F, good point to drive discussion
- Deferred until after F2F

>> ------
>> ACTION: Scott will propose text that documents the detailed
>> semantics of NameIdentifier.
>>
>> Status:
>>
http://lists.oasis-open.org/archives/security-services/200110/msg00067.html

>>

- Scott is not on call
- Deferred to next call

>> ------
>> ACTION: Krishna to drive SAML profile of xmldsig.
>>
>> Status: in progress. First draft doc sent to list.
>>

- Krishna
  - Little response to messages posted on list
  - Asking Phill directly about changes proposed in message on list
    - Phill: Makes sense to add XMLDSig element
    - Question of cardinality of assertions within a signature
      - Eve: Having multiples not part of SAML proper
      - Chris McLaren: what’s the problem? Can’t signature assertion
        semantics just extend to multiple statements?
      - Irving: no way for requestor to express ability to handle
        multiples versus singles
      - Most likely only used for Attribute Assertions
      - Chris: Semantic problems are the same for one assertion w/
        multiple statements as for multiple assertions each w/ one
        statement
        - Multiple statements under one assertion header is already
          in Core 19
      - Gil: implementing the former is easier than latter
      - Chris: just did it, not that different
      - Irving: issues is adding another layer of multiplicity, but
        semantics issues are the same
      - Dave O: at F2F#3, had recommended XMLAny approach
      - Chris: we did that, just worded differently
        - We have strongly typed assertions
      - Can still send more than one assertion in a response -- not
        forced to lump all into one with single set of validity
        data, etc.
      - No intended semantics among statements that are lumped into
        one signed package, but some implementer will invariably
        assume some semantic meaning
      - Bob B: Is it reasonable to provide optimizations that are
        potentially problematic in advance of measured performance
        issues?
      - Gil doesn’t want to take something that is potentially bad
        and make it worse
      - Irving wants one or other: assertions always have multiple
        statements or multiple assertions always have one statement
        each
      - Eve warns against allowing semantic holes in our spec, and
        this situation causes nervousness
- Enough discussion for now

>> ------
>> ACTION: Don: to elaborate the number of 1-1 relationships and
>> propose how to fix the resulting scaling issues.
>>
>> Status: AI still open. to be sent out to list by October 8, 2001.
>>

- Don not on call
- Deferred to next call

>> ------
>> ACTION: Gil to write up background semantics and background
>> assumptions on relationships btwn NameIdentifier(s) and
>> subjectConfirmation(s) within Subject elements.
>>

- Sent to list.  Includes proposal to modify Core19
  - Irving: going in circles with Core16 and Core19.  Irving wants
    just one identifier, which aligns closely with Gil’s proposal
  - Gil: Multiple subject specifiers not necessary
- Read and comment on list
- Closed

>> ------
>> ACTION: Prateek: "Security properties of Assertion Handle"
>>
>> Status: in progress. Will make progress by October 10, 2001.
>>

- Prateek: Will move on this this week
- Still open

>> ------
>> ACTION: Tim, Simon, Prateek (champions): compose complete
>> recommendation for "Relying Party tailors assertion in browser
>> artifact profile"
>>
>> Status: Text has been proposed on the list, for both core and
>> bindings docs. have some work to do to align. should stay open
>> till we see a protocol schema that accoomodates the requrement.
>>
>> still open.
>>

- Text has been delivered to Prateek.  Must be integrated into doc.
- Still open

>> ------
>> ACTION: Marlena, Scott: to champion the "context info in attr
>> query" issue.
>>
>> Status: Scott: will propose explicit text & schema
>>

- Write-up sent out to list
- Read and comment on list
- Closed

>> ------
>> ACTION: Scott, Marlena: to champion "attribute scope"
>>
>> NEXT STEP: Scott will post followup folded into Phill's thread
>> (subject of thread will change to something more enlightening
>> hopefully). the thread..
>>
>> "options for change"
>>
http://lists.oasis-open.org/archives/security-services/200110/msg00021.html

>>

- Scott not on call
- Marlena has nothing to add to Scott’s messages on list
- Still open

>> ------
>> ACTION: Simon: to champion "Query refinement proposal"
>>
>> still open. we'll see if this proposal garners any support. If
>> not, we will enter into Issues list with a disposition of
>> "deferred".
>>

- Deferred to F2F#5



------
New Discussion Item: single/multiple assertion question  (Irving)

- Topic handled earlier.  Withdrawn



------
New Discussion Item: senderVouches security model  (Prateek)

- Originated in Bindings subgroup
- Prateek has written up proposal message, and suggests everyone
  read and comment
- Message not on list yet, but will be
- BobB: Is scenario useful to anyone?
  - Prateek believes so.  Just a question of how to architect it.


--
Steve Anderson
OpenNetwork Technologies
sanderson@opennetwork.com
727-561-9500 x241

begin:vcard 
n:Anderson;Steve
tel;fax:727-561-0303
tel;work:727-561-9500 x241
x-mozilla-html:FALSE
url:www.opennetwork.com
org:OpenNetwork Technologies
version:2.1
email;internet:sanderson@opennetwork.com
title:Product Architect
adr;quoted-printable:;;13577 Feather Sound Drive=0D=0ASuite 330;Clearwater;Florida;33762;USA
x-mozilla-cpt:;-15216
fn:Steve Anderson
end:vcard


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


Powered by eList eXpress LLC