[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes from focus group conference call, Dec 2, 2003
SSTC focus call 2003-12-02 ---------- attendees: Mike Mcintosh Mike White Scott Cantor Frederick Hirsch Prateek Mishra John Hughes Rob Philpott John Linn Jim Lien Santil Sangodin [Minutes by Bob M] agenda: go thru work items, clarifying status and to-dos, including agreement required W-1: there will be vote about scope of session support W-2: use case clear, we are ready to vote to accept (or not) W-2a: [AI] Prateek will update draft based on comments. Scott: Shib has some discussion about metadata to contribute Scott: and encryption of attributes? Prateek: will update to note encryption requirements so, question to TC is simply: accepting this use case W-3: Prateek: use case submitted, discussion happened Liberty submission is solution proposal Scott: Shib submission is consistent, just writing down Shib practice Prateek: so use-case submitters need to work with Jahan to modify solution document W-5: [AI] Prateek to propose solution, others review to make sure their requirements are captured. W-5a: LECP submitted, combine with generic SOAP client? FH: confusing to combine, how about making separate work item Prateek: agree, will create distinct item for SOAP client so Eve (as W-items maintainer) is so directed, to be item W-5b Scott: point about LECP is it's modest extension of browser profile where SOAP client is new profile Prateek: Tony submitted use case in October ... Scott: don't need lots of justification for SOAP ... RLM: is "SOAP client" precise enough? Scott: part of item is defining it precisely enough RLM: some relationship to WSS SAML token profile COMMENT: Split into W-5a, W-5b, vote on each separately, need an owner for 5b W-6: doc submitted Scott: tactical proposal, not grand architecture some relation to delegation/intermediary COMMENT: Single use-case, ready for vote W-15: RLM: this is very general SSTC has to consider how big the scope is for this one more concrete use case that has been mentioned is "native SAML" delegation approach Scott: will try to submit writeup on this Prateek: can vote on acceptance of some specific concrete use cases? RLM: yes, also evangelize others to write theirs up this week, based on model COMMENT: family of use-cases, we need to figure out exactly which piece should go into SAML 2.0 W-21: RLM: potentially much larger requirement here for complete mapping between ASN.1/X.500 and XML XED work, discussed in IETF, see internet-drafts draft-legg-xed-* is deep and complete on this topic will describe potentially larger scope in message to TC Prateek: so vote on accepting this limited use case or larger one? RLM: yes [Minutes by Rob P] W-7: Prateek: No major issues. Need to vote up/down. W-8: Prateek: No major issues. Need to vote up/down. w-9: see Hal's message John Linn: Use case #4 generally results in solution options that are particularly messy and complex. Should try to constrain it? Scott: some of the listed requirements (e.g. schema validity) depend on the use case. It depends on where the encryption processing takes place relative to SAML processing. Use case 3 may already be met because of the content model used with the elements mentioned. Rob: The use cases should make sure to also address protocol requests and responses as well as the assertion. COMMENT: we need to dive deeper and refine scope for this use-case W-17: Ready to vote up/down. W-19: Ready to vote up/down. W-25: Kerberos John Hughes: Should probably split them out as separate profile proposals for voting. Credential conversion idea (3.1) should be tabled for now. The browser profile (3.2) should move forward for a vote. W-28a: Suggest splitting into 2 parts: 1-codification of existing attribute namespace usage within the specs; 2-reconciling with XACML. Get owners and then vote on them separately. Perhaps need some more discussion and analysis of Tony's response. COMMENT: W-28a-(1) refers to describing current practice in SAML 1.X, W-28a-(2) refers to existing work item which should also acknowledge current practice as described in W-28a-(1). W-28d: Ready for up/down vote. See Scott's message from 30-Oct re: Issuer/Name Identifier overlap. There are actually 3 solution proposals: 1- Rebekah's; 2 - do nothing (Scott's item (a)); and 3 - Scott's item (b). [end of work item discussion] Scott: This is already on the issues list, but we need to improve the extensibility points within the specs to make it possible to deliver extension "profiles" off the main spec schedule. Prateek Mishra Director, Tech&Arch Netegrity p: 781-530-6564 c: 617-875-4970
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]