[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes for SSTC Conference Call, April 12, 2005, v1
(a) http://lists.oasis-open.org/archives/security-services/200503/msg00109.html
Approved without objection
2. On-going CD vote for Metadata Extensions Draft (PLEASE VOTE!)
Vote closes Wednesday, April 13, 9AM Eastern.
http://www.oasis-open.org/apps/org/workgroup/security/ballot.php?id=730
Please vote today. No other comment.
3. Is CD status appropriate for informational documents?
OASIS Response:
http://lists.oasis-open.org/archives/security-services/200503/msg00113.html
OASIS response indicates it is appropriate if TC so decides.
Prateek - plan to bring response paper back for vote at next full meeting.
4. Other informational
notices
A. Request for SAML 2.0 speaker
http://lists.oasis-open.org/archives/security-services/200504/msg00062.html
Jahan - it is likely that Jahan will give presentation in May. They may be looking for a tutorial in September.
B. SAML 2.0
slide-set uploaded (dates from Decemeber 2005, add to document repository)
http://lists.oasis-open.org/archives/security-services/200504/msg00069.html
Prateek has posted some slides to repository.
Vote to move to CD status on this
Frederick - moved
Eve - seconded
Tony - has been cd draft in the past, not sure this is something for an "executive", what is the target audience?
Paul - was meant to be summary for executive. What is your specific concern?
Tony - a technical executive could understand it, but I know some that would not understand it
Gordon - excellent high-level overview, but it is technical
Eve - appropriate for technical managers managing implementers
Paul - not meant to be marketing
Gordon - for technical managers
Eve - executive overview means summary
Jeff agrees.
Scott - thought it was a CIO document, technical document
Eve - CIO's should understand it.
No other comments.
Vote passed without objection. Executive overview draft moved to CD status, since 2/3 voting members present.
6. Reminder: Andy
Moir is looking for feedback on V1.1 spec conformance certification
program. Review period has now closed (April 11).
http://lists.oasis-open.org/archives/security-services/200503/msg00054.html
Comments:
A. http://lists.oasis-open.org/archives/security-services/200504/msg00079.html
B.
http://lists.oasis-open.org/archives/security-services/200504/msg00083.html
Andy has received additional private comments, will put together response to all comments while protecting privacy of private respondents. Will send email to SSTC list today or tomorrow.
Tony - how is final decision be made?
Andy - will send response for feedback, then to Patrick Gannon and OASIS board.
Tony - this directly effects the TC, so is the TC out of any vote process here?
Andy - This is a referral arrangement, not a direct OASIS program, hence not controlled and operated by OASIS and TC. Program already exists outside of TC today.
Tony - would like to see this addressed in comments. Not sure of value if not something everyone can use.
Andy - Understood
Greg Whitehead - Reiterates concern of any vendor running a program for other vendors in the industry - a competitive concern
Eve - has similar concern
Andy asks for specifics
Eve - If one vendor is elevated among others as gatekeeper, means company might have to bring early versions of product to a competitor, not something a vendor might want to do
Greg - can make long list of specific concerns, but there is a major concern related to a conflict of interest - a company selling a product and also gating how other companies can bring products forward - even if everything done well
Heather Hinton - PingId could get stamp of approval, simply by being chosen
Prateek has additional comments
Darrin - When the group is formed to govern this service, these concerns were raised and addressed, so how concerns are dealt with should be in Andy's response.
No other discussion
7. SAML 2.0 Technical Overview (new draft uploaded April 11)
Comments:
http://lists.oasis-open.org/archives/security-services/200504/msg00076.html
Eve - needs a lot of work, suggests Prateek add his material and planned changes.
Prateek plans to generate next version.
Prateek - Please review, will save time answering questions later.
8. Attribute sharing profile for X.509-based Authn (new draft uploaded April 5)
http://www.oasis-open.org/apps/org/workgroup/security/download.php/12155/sstc-saml-x509-authn-based-attribute-protocol-profile-2.0-draft-03.pdf
Comments:
A.
http://lists.oasis-open.org/archives/security-services/200504/msg00042.html
Rick is not on the call, but a new version has been published as well as comments noted.
Tom - submitted editorial comments to Rick who plans to update the document.
9. Errata Document (new draft uploaded April 11)
This draft
(04)
has proposed text for all PEs except PE 10. New errata was
discussed on focus call of April 5.
http://lists.oasis-open.org/archives/security-services/200504/msg00038.html
Note: PE5 is still open and subject of extensive thread discussed below.
Jahan - two minor corrections have been made this morning but not posted . Haven't added material from focus call last week, will add to next version.
Scott's proposals for PE resolutions were sent before last week's focus call.
PE1 - relay state for HTTP redirects - Scott posted proposal 2 weeks ago, reviewed in focus call.
Scott's proposal accepted without objection.
PE2 - language clarification
Scott's proposal accepted without objection.
PE3 - missing piece, doesn't break anything
Scott - need to add to extension proposal for this, so suggest this be moved to issue list for future extensions or revisions
No object to moving to issues list.
Prateek - is there an issues section?
Jahan - no, who keeps the issues list?
Rob asks whether Eve was the last owner of the issues list.
Eve - all 2.0 issues were closed, one issues was deferred.
Agreement to start new post-2.0 issues list, including this PE and the deferred item from the current issues list.
Jahan offers to own new post-2.0 issues list.
PE4 Language proposal from Scott
Scott's proposal accepted without objection.
PE5 - text proposed, then a correction to change persistent to transient, be aware of this.
Scott - suggest we have more discusson on general AllowCreate question to be resolved, Scott's proposal was early. Need specific proposals from others related to this concern.
Discussion will be required on list.
Open issue.
PE6 Language proposal from Scott
Greg - ok if there is a use for it.
Scott's proposal accepted without objection.
PE7 combine with PE9
Prateek - This was discussed briefly on focus call
Scott - interop participants should review
Open issue, pending review by all.
AI - Rob to review PE7
PE 8 Proposal from Thomas
Prateek - scope?
Scott - limited to termination
No implicit logout in MNI.
Prateek, just terminate or include update
Thomas - Just terminate
Proposal accepted without objection.
PE9 - merged with PE7
PE10, Open, Jahan to propose text.
Jahan - Where to put PEs when closed, since it will disturb E section. Propose not changing any numbers, PEs stay the same, once everything closed, then re-number and re-order. Plan to post new version by tomorrow.
10. Open AIs
#0221: Request copy of Thomas Grosz paper for inclusion in SSTC archives |
Owner: Maryann Hondo |
Status: Open |
Assigned: 2005-04-12 |
Due: ---
Prateek
asks on status. Maryann wrote letter to IEEE, waiting for reply - issue is
IEEE copyright. Paper is available on net, but goal is to have
copy.
Open. |
|
#0220: Respond to Rick R on subject confirmation issue on the X509 Attribute Sharing Profile |
Owner: Scott Cantor |
Status: Open |
Assigned: 2005-03-30 |
Due: ---
Open |
|
#0219: Propose specific errata text for E4 |
Owner: Scott Cantor |
Status: Open |
Assigned: 2005-03-30 |
Due: ---
Closed |
|
#0218: Propose specific errata text for E3 |
Owner: Thomas Wisniewski |
Status: Open |
Assigned: 2005-03-30 |
Due: --- |
Closed
|
#0217: Explore with OASIS how best to do publication of redlined specs based on errata. |
Owner: Eve Maler |
Status: Open |
Assigned: 2005-03-30 |
Due: ---
Eve sent
mail message to Mary McCrae on 30 March, will re-send.
Open |
|
#0216: Formulate some suggested redline text for E7 for review. |
Owner: Jahan Moreh |
Status: Open |
Assigned: 2005-03-30 |
Due: ---
Open |
|
#0213: Prepare final CD draft of metadata-1x document and submit it to OASIS |
Owner: Eve Maler |
Status: Open |
Assigned: 2005-03-29 |
Due: ---
Open
Eve offers
to also take care of executive overview. |
|
#0210: Links to new IPR policy to be sent to SSTC |
Owner: Rob Philpott |
Status: Open |
Assigned: 2005-03-15 |
Due: ---
Open |
|
#0208: Run additional tests to check issues with deflate encoding and rfc1951 (java libraries) |
Owner: Scott Cantor |
Status: Open |
Assigned: 2005-03-01 |
Due: ---
Open |
|
#0180: Need to update SAML server trust document |
Owner: Jeff Hodges |
Status: Open |
Assigned: 2004-07-12 |
Due: ---
Open
new AI -
Prateek - Revise tech overview, v produce ersion 05
draft
Eve/Scott
proposes links to external material explaining SAML, including
Wiki. |
11. Discussion threads
A. XPath attribute profile
Prateek - What should TC be made aware of? Status?
Cameron - plans to update document, simpler version, enumerate supported XPaths. Would like to pursue CD status eventually?
Prateek - please upload PDF version as well
i. request for pdf version of file
http://lists.oasis-open.org/archives/security-services/200504/msg00072.html
ii. Use-Cases posted to list
http://lists.oasis-open.org/archives/security-services/200504/msg00044.html
iii. XPath Attribute Profile: XPath as an Identifier
http://lists.oasis-open.org/archives/security-services/200504/msg00049.html
iv. XPath Attribute Profile: XPath URI as a URN
http://lists.oasis-open.org/archives/security-services/200504/msg00050.html
B.
PE5 - NameIDPolicy (Should this be re-named?)
i.
Proposal From Scott Cantor
http://lists.oasis-open.org/archives/security-services/200504/msg00048.html
ii. Discussion
http://lists.oasis-open.org/archives/security-services/200504/msg00075.html
http://lists.oasis-open.org/archives/security-services/200504/msg00077.html
http://lists.oasis-open.org/archives/security-services/200504/msg00080.html
Prateek - need to rename.
Brian - this portion of the specification may be more general than intended, but other portions of the spec are also very general. A profile may be needed here, rather than modifying core.
General discussion regarding correct approach, specification/conformance changes, whether missing a profile or whether this is part of SSO profile.
Prateek - suggests smaller group work on this issue.
Scott - need to allow pre-provisioned name identifiers.
Greg - perhaps "unless name identifiers managed out of band, then ..."
Scott - proposed text along these lines. SP can't assume what IDP will do, given flag.
Greg - out of band, means both sides agree.
Prateek - federation agreement is at another level
Rob - this can be interop issue
Scott - need to hear example of this
Brian - IDP has stricter reading of AllowCreate, will not issue identifiers unless True, other implementations will not use flag, then default is false, deadlock since IDP waiting to create identifier but not allowed to
Scott concurs, hence wanted default to be True, but Liberty requirements were different.
Brian - false value raises issues.
Scott, can you propose improved wording? Not clear whether this is IDP discretionary
Treat as advisory data from SP, decision at IDP, an audit viewpoint
Brian - Relationship to Consent attribute is not clear
Scott - added wording regarding this
Brian - needs to understand consensus of group
Prateek agrees with audit viewpoint, will review Scott's wording.
Scott suggests additional improvements to proposed wording would help. Looking for agreement that flag is intended as input to IDP processing, rather than indicating normative behavour
Rob - local policy discretion is applied to everything we do
Brian - what is value without processing rules
Greg what if, "IDP implementations that strongly protect user privacy may refuse to return an identifier if AllowCreate is not set to true", this allows SP to decide whether reason to set AllowCreate to false (protect SP in privacy circumstances) otherwise always set to true.... This would be appropriate for cases where privacy matters (e.g. Liberty) and ability for SP to express policy to IDP (enabling audit of SP behavour)
Rob in case false is set, IDP can only use pre-decided name identifiers
Greg - Liberty use case, circle of trust using cookie introductoin mechanism, (1) SP knows location of IDP even though haven't visited, no state or cookies, then application wants to personalize page, see if authenticated at IDP, set AllowCreate to false, don't want to establish federated relationship, would rather have explicit federation request if not in place already. Don't want federations to occur silently, enabling unclear tracking
Discussion converging toward audit approach.
Greg - Different policies at IDP might result into different behaviours based on AllowCreate, this can give SP guidance on use of flag.
Brian - some SPs will always use false
Greg - offers to get Liberty feedback next week at Liberty F2F
Scott will take another pass at wording, reflecting this discussion
Greg - could propose extension to metadata to define how this is used
Continued discussion on whether there is agreement on taking audit/hint approach, or another profile approach. Questions about how these profiles would compose.
AI Scott to provide revised proposal text.
Meeting Ajourned.
-------------------------
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]