[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
Attendees:
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
Agenda
- 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.
1.3.2.2", 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
issue
- 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
user
- 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
point
- 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
profile
- 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
protocol
- 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
interop
- 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
Core19?
- 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
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