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: minutes for SSTC focus call, 2004-03-23


 - RL "Bob"


minutes for focus group conf call, 2004-03-23


 *  Mike Beach, Boeing
 *  Tim Alsop, CyberSafe
 *  John Hughes, Entegrity
 *  Irving Reid, HP
 *  Paula Austell, IBM
 *  Scott Cantor, Individual
 *  RL "Bob" Morgan, Individual
 *  Prateek Mishra, Netegrity
 *  Frederick Hirsch, Nokia
 *  Darren Platt, Ping Identity
 *  Rob Philpott, RSA Security
 *  Jeff Hodges, Sun

discussion of various documents:

Kerberos solution proposal:

comment from John Linn that most of this profile content is common
  with other browser profiles, can repetition be reduced?
Scott:  I am planning to submit browser SSO profile to tie things together
  this would be the common text to be referred to from others
Scott:  what is it that authenticates with Kerberos?  browser?
JohnH:  could use applet to authenticate to inter-site service
  section 3.3.9 describes this
Scott:  is it the browser or the applet that delivers assertion to SP?
TimA:  isn't this an implementation detail?
Scott:  browser authn to IdP is already not constrained by our profiles
  so don't have to write anything specific to support Kerb for this
  can't tell if this is a new profile
    if browser is delivering the assertion to SP, then it's not
Scott:  description of Kerb authentication to IdP isn't SAML profile
  since authn to IdP isn't covered by SAML
  so maybe this is just a conformance issue, saying "use Kerb for this"
  but doesn't seem to affect existing browser profile
[extended discussion of profiles, bindings, GSS, SASL, etc]
JeffH:  defining SAML-based authentication service is a larger task
  and a separate spec
JohnH:  comments are that SASL stuff should be in separate doc
  in separate timeframe
  and that GSS is closer and more understandable
TimA:  but SASL seems more of interest, so focus on that now?
BobM:  but are these do-able for SAML 2.0?
JeffH:  good to have SASL for some 2.x of SAML
TimA:  discuss at F2F in more detail?
Scott:  will read doc and use as input
JohnH:  John Linn's other point was this one about bindings ...

RobP:  list discussion on artifact binding ...
Scott:  name of message isn't a big deal ...
  question is whether thing coming back is always Response ...

baseline attributes doc:

JohnH:  also want to cover UUID/GUID space, is this covered by standard?
JeffH:  this is still just an internet-draft, I think
  [yes, draft-mealling-uuid-urn-03.txt]
JohnH:  also want human-readable name along with AttributeName
Irving:  grumble, people will just string-match on these instead
BobM:  justification can only be that in the case where the recipient
  doesn't understand the OID, the friendly-name can be a hint on use
  but that is fraught with problems
  and doesn't replace real publishing of schema, which we're not covering
[discussion of whether to cover attribute "semantics" in this doc]
Prateek:  will do new version

attribute doc (maler-W28a):
Eve is not on the call ...
Scott:  seems like XACML folks have strong opinions,
  will they be represented at F2F?
RobP:  probably just Hal
  maybe should make time for a phone call with interested parties
    during the F2F

encryption doc:  Hal's proposal seems reasonable, nail down at F2F

metadata doc:  some discussion on list ...

attribute name representation issue:
Irving:  can't we name SAML Attributes with just a URI only?
Scott:  seems like inclusion of Source concept gets rid of most of
  motivation for AttributeNamespace/NameFormat
Irving:  also potentially a use for policy grouping?
BobM:  seems like justification can only be that someone has bundle of
  attributes, doesn't want to bother defining URIs
Irving:  some claimed that they didn't want to have to have URI parser
  just to handle attributes
Scott:  but other decisions have made that argument moot
BobM:  so proposal is just to get rid of NameFormat, and Name is just URI?
Scott:  could even have Name be just a string,
  just say the profiles we're defining happen to use URIs only
Irving:  always have to have a mapping between thing sent and local store
Scott:  mostly just want to get rid of NameFormat
RobP:  will proposal be made to list?
Irving:  OK, will follow up on existing thread

F2F agenda:

Prateek:  several open issues on bindings/profiles, right?
Scott:  yes, URL encoding, etc
[more agenda discussion]
RobP and Prateek will develop proposed agenda, send to list
TC members encouraged to post items desired for discussion
Prateek:  people may not be clear on what's considered "finished"
  and what not, in the core specs,
  so should start by going thru and clarifying this
RobP:  don't want to open everything up for discussion again
BobM:  chairs will have to be firm about not re-opening closed items
  and TC members will have to exercise restraint ...

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