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