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 Focus Group, Tuesday Oct 23

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

    Allen Rogers Authentica
    Irving Reid Baltimore
    Simon Godik Crosslogix
    Gil Pilz E2open
    Hal Lockhart Entegrity
    Tim Moses Entrust
    Don Flinn Hitachi
    Joe Pato HP
    Jason Rouault HP
    Chris McLaren Netegrity
    Prateek Mishra Netegrity
    Steve Anderson OpenNetwork
    Darren Platt RSA
    Phillip Hallam-Baker Verisign
    Thomas Hardjono Verisign

    Scott Cantor IBM

    - Non-closed Action Items from last concall
    - New Items:
        - Simon’s proposal sent to list
        - Chris:  Shib status codes

Action item:  Scott will propose text that documents the detailed
semantics of NameIdentifier
    - Sent clarification to list
        - Subject line was "Suggested addition to core-19.doc, sec.
", dated Oct 9
    - No discussion on list so far
    - Prateek:  so we are not going to call out any distinguished
      name identifier scheme for purpose of pseudonymity?
        - Scott: correct
    - Joe: move issue to being closed & accepted
        - Phill making change in Core doc
    - Closed

Action item:  Krishna to drive SAML profile of xmldsig
    - Tabled

Action Item:  Don to elaborate the number of 1-1 relationships and
propose how to fix the resulting scaling issues
    - Considering pulling issue
    - Issue of number of capacity to handle large number of
      simultaneous connections
        - Can be dealt with in implementation & deployment
    - So, can't do anything about problem, and it can be solved
      with additional hardware
    - Closed, Withdrawn

Action item:  Prateek "Security properties of Assertion Handle"
    - Still open
    - will send text to BobB by Friday

Action item:  Tim, Simon, Prateek (champions): compose complete
recommendation for "Relying Party tailors assertion in browser
artifact profile"
    - Prateek:  Essentially closed
        - Text has been received by Prateek
        - will update draft and share with bindings group
    - Tim sent proposal to Phill, who made counter proposal, mainly
      due to differences in Core 16 & Core19
        - [ACTION: Tim] Tim to propose how to modify core19 (rather
          than core16)
    - Joe:  Try to have closed by next week

Action item: Scott, Marlena to champion "attribute scope"
    - Current approach in Core doc is sufficient
        - Allows arbitrary XML in attribute assertions
    - Closed

Action item:  Simon: to champion "Query refinement proposal"
    - Still deferred to F2F#5

Action item:  Prateek -- senderVouches security model
    - Sent text to list
    - Got responses from Bob & Mack Hicks
    - Integrated into bindings draft
    - Bindings call this week will cover further
    - Keep open until next week

New Item: Simon’s proposal
    - In email w/ subject "Attribute Authority information in
      Authentication Assertion proposal", dated Oct 22
    - Joint submission with scott & marlena
    - Orig context
        - From Shib design
        - Relying party doesn't know what Attrib authority to use,
          based on authN assertion
        - Wants to include indicating info in authN assn, using URI
        - AuthN assn will only point to attrib authority
    - Joe:  how is attribute linked to authority?  How is attrib
      scoped to authority?
    - Simon:  not scoped, up to RP, mainly for purpose of obtaining
      attrib assn
    - Chris:  had asked list whether this is in scope?
        - No response from list.  Talked to Simon directly.
    - Prateek:  agrees with question, believes this is a provisioning
    - Chris:  Shib must have it, but it may not be in scope for SAML
    - Chris:  allows info on subjects to include reference for
      additional info
        - If there is a way to do it with a Dir Svc, that's fine
        - Simon focused (correctly) on problem of different Attrib
          authorities responsible for diff segments of information on
    - Scott
        - Given an AuthN event at an origin site, where does a RP go
          for more info?
        - Attrib authorities are inherently dynamically related, so
          only way to know is from AuthN assn
    - Chris: still a question of in/out of scope for SAML 1.0
    - Scott:  if not in scope, what extension point would be
      appropriate for this type of functionality?
        - Chris:  clarifying that he's not for or against at this
        - Irving:  suggests Advice over Conditions, since conditions
          affect ability to use current assertion
            - Use of Advice limits interop
    - Irving:  any other uses beyond AuthN event?
        - Scott:  can't think of any, but there could be
    - Simon:  Shib is first app of SAML, so we should ensure that
      Shib requirements are met
        - Scott:  Shib hopes to be able to swap various SAML
          implementations in and out
        - Irving:  his company making progress on Web browser Pull
    - Prateek:  core issue is that only authN authority has
      knowledge of attrib authority
    - Scott:  moves to table, so that people can think about question
      of scope
    - Don:  how to express subject of attrib request to attrib
      authority?  Particularly when authority needs proof of
      authentication of the subject
        - Subject field may be filled with just a name, or with an
          authN assn
            - Irving:  authN assn in subject was not originally
              intended for this purpose
            - there's no use case to support this, not that this use
              is not valid
        - Trying to address Shib problem of controlled release of
          information about users
        - possession of authN assertion doesn't prove that entity has
          authenticated session with user, so this may not be useful
          for the problem at hand
        - Don:  out-of-band trust relationship should have already
          been estab between authorities, which, combined with AuthN
          assertions, may be sufficient
        - [ACTION: Don]  Don to add discussion material on list
    - tabled

New Item: Scott's status codes
    - doesn't really have proposal on table
    - got impression that at some time later, this would eventually
      be covered
    - drawing attention to section 3 of core19
        - case of error being returned expressing incompatible
    - existing four status values in current schema are limiting
    - work is Shib is resulting in a running list of new status codes
    - just raising visibility of need for more expressiveness
    - not trying to make fuss prematurely
    - [ACTION: Scott] Joe:  recommends Scott outline a proposal

Prateek:  reopening first issue (Scott's proposed text that documents
the semantics of NameIdentifier)
    - Question on interop:
        - Presumably, cases where one sec domain communicates with
          another sec domain, won't something be necessary to enable
        - Scott:  that was Marlena’s point
        - Shib doesn't have use case for it, but others may
        - Scott's current wording reflects current spec, which
          doesn't have a more formal mechanism
    - Prateek will consider whether to raise this as issue
        - Joe:  changing structure of NameIdentifer later (post v1.0)
          will be difficult, so it should be considered carefully now
        - [ACTION: Prateek]  Prateek will place issue on list today

Issues to consider for next Tuesday's ConCall
    - Agenda for F2F
        - Date/location confirmed (20+ confirmed attendees)
        - Downtown SF at Bank of America
        - Can book flights now
        - Other logistics will follow soon
    - Phill Editorial question:  Any other agreed-upon changes for
        - Multiplicity of NameIdentifier still in question
        - Basically, no
        - A few concrete proposals have been floated, but no
          consensus has been reached on them
            - Action items have been closed, but their related issues
              have not
            - [ACTION: Issue Champions]  Up to champion to drive to
              vote, etc
    - [ACTION: Everyone]  Phill wants everyone to look through Eve's
      proposed restructuring of document

Steve Anderson
OpenNetwork Technologies
727-561-9500 x241

tel;work:727-561-9500 x241
org:OpenNetwork Technologies
title:Product Architect
adr;quoted-printable:;;13577 Feather Sound Drive=0D=0ASuite 330;Clearwater;Florida;33762;USA
fn:Steve Anderson

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

Powered by eList eXpress LLC