[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: minutes for 27-July SSTC con-call
|
> Dial in info: +1 865
673 6950 #351-8396 [Minutes provided by Rob] Attendance list at end of
official meeting minutes 1. Accept minutes from July
20 conference call http://lists.oasis-open.org/archives/security-services/200407/msg00134.html * Approved by unanimous
consent. 2. Status of last call
review * Plan for next week’s
call -
need to collect all last
call comments and work through them -
The current schedule makes
it tight to be able to complete the 30-day review period, apply all updates,
revote for CD, and complete the paperwork for OASIS submission. For an
October vote, the submission must be made by the 15th of September. -
Current target is to vote
for CD on 10-August. -
Both Prateek and Rob may not
be able to run the call next week. o
Rob, Prateek, and Eve will
talk on Monday re: handling next week’s call a. Proposal to extend
meta-data with attribute values http://lists.oasis-open.org/archives/security-services/200407/msg00127.html Scott – this can be
grouped with Anne’s comments to the list this morning as well. [Scott worked through his
proposal on the list] – the basic idea is to derive off of AttributeType
rather than AttributeDesignatorType. This allows including attribute
values in the metadata. Peter D – Does this
require any changes to profiles? Scott – doesn’t
add any processing rules to SSO profiles, although there may be some needed
there anyway. Probably need to include some text in the attribute
profiles. Although we could dodge the profiles work by adding text in the
metadata description. RL Bob - Move to accept
Scott’s proposal to update the metadata draft Peter – Second *** Vote: No objection to
unanimous consent. Eve dropping off call
– puts in a plea for input on the technical overview document
(particularly Kerberos – Tim Alsop?). Please send chunks of text asap. * Discuss Anne
Anderson’s message: http://lists.oasis-open.org/archives/security-services/200407/msg00148.html Prateek - This is a change
to the runtime and processing rules Rob – does she want
this to be a MUST in terms of processing rules? Scott – yes. RL Bob – the only
feasible meaning for this is to filter out values returned by the authority. Scott – there are a
number of use cases, one of which overlaps with what we just dealt with in
metadata. <general discussion of
semantics when the attribute value requested doesn’t match the value at
the authority> RL Bob – what if I ask
for attr A with value X and attr A with value Y? Scott – Need a prose
rule saying that the same attribute should not be named more than once. Scott – told Anne that
if there weren’t major objections to her mail, he would propose text on
the list. *** AI: Scott will propose
text and schema changes. Scott – This also will
simplify the schema since there will no longer be a need for
AttributeDesignator since it will never appear separate from AttributeValue. b. Comments on sstc-saml-core-2.0-draft-17.pdf http://lists.oasis-open.org/archives/security-services/200407/msg00128.html Scott – main item to
be discussed is that we need some text up from better describing
NameIdentifier. Not hearing any objections (on the list), Scott will, by the
next call, work through them and incorporate as appropriate. *** AI: Scott to incorporate
the notes c. Corrections to
Sstc-saml-bindings-2.0-draft-16.pdf http://lists.oasis-open.org/archives/security-services/200407/msg00136.html Scott – these are
editorial in nature. d. detailed comments on sec
4.2 Enhanced Client and Proxy (ECP) Profileofsstc-saml-profiles-2.0-draft-17 http://lists.oasis-open.org/archives/security-services/200407/msg00144.html *** AI: Scott and Jeff will
coordinate offline to incorporate the changes. 3. New drafts SAML 2.0 Technical Overview
uploaded http://lists.oasis-open.org/archives/security-services/200407/msg00133.html * See Eve’s previous
plea to provide additional text/comments. sstc-saml-2.0-issues-draft-13-diff.pdf
uploaded http://lists.oasis-open.org/archives/security-services/200407/msg00126.html BIND-4: Scott sent a note to
the list http://lists.oasis-open.org/archives/security-services/200407/msg00124.html We should leave this open
for now. 4. Open AIs #0188: Update conformance
document with focus call input Owner: Prateek Mishra Status: Open * Prateek –
haven’t made much progress. Have comments to include from the focus call.
Would like input from TC on the note from Scott this morning. Should all the
queries be lumped together in one conformance “operational modes”
(SAML Responder)? Main issue is the AuthzDecision response from a PDP. Instead
of one SAML Responder operational mode, divide them up by the 3 types of
authorities. * Concensus seems to appear
that this is okay. * Steve – Has a
similar concern over LogoutRequest and LogoutResponse being Mandatory To
Iimplement when delivered over SOAP. It isn’t meaningful if the
system requires interaction with the browser. * Scott – this would
mean that the receiver can’t carry out the request and thus
wouldn’t be conformant. * Jeff – it was
intended to facilitate deployment options. * Scott – this would
be a conformance decision making it a requirement for an implementation to work
a certain way. * Steve – this
undermines the meaning of conformance. They can’t all go together.
Putting both in the MTI category is unreasonable. We just need more granularity
or, in this case, SOAP can’t be the MTI. * Scott – agrees. * Prateek – * Prateek – Another
concern is assuming that each operational mode can write back to some persistence
store. Still open. #0187: Broaden Conformance
Introduction Owner: Eve Maler Status: Open This should be rolled into
AI #182. _____ #0186: Proper use of URIs
results in uniqueness Owner: Scott Cantor Status: Open This is a dup of AI 181.
Need to close. #0185: Rationalize presence
of empty elements in schema Owner: Scott Cantor Status: Open Still open. #0184: Send SSTC response to
Thomas Grss paper to the author Owner: Status: Open Still open. #0183: Comment s solicited
on John Linn response to Thomas Gross paper Owner: Prateek Mishra Status: Open Still open. #0182: Use Conform. doc as
entry point to docs Owner: Eve Maler Status: Open Still open. #0181: Explain that proper
use of URIs results in uniqueness Owner: Scott Cantor Status: Open Still open. #0180: Need to update SAML
server trust document Owner: Jeff Hodges Status: Open Deferred. Still open. #0179: Does conformance meet
pki-cross-domain-profile-draft-01.doc requirements? Owner: Rick Randall Status: Open Still open. #0176: Provide sequence
diagrams for profiles Owner: Jeff Hodges Status: Open Still open. Hope to close
this week. #0175: Add Security Context
to glossary Owner: Jeff Hodges Status: Open Still open. #0166: Investigate use of
Wiki from teh web site Owner: Scott Cantor Status: Open Still open. #0163: Need process for
submission of profiles/authn context classes, etc. Owner: Rob Philpott Status: Open Still open. #0160: Separate Privacy
concerns language from Element/Attribute descriptions Owner: Prateek Mishra Status: Open Still open. #0158: Propose changes to
definition of Federation in glossary Owner: Prateek Mishra Status: Open Still open. #0157: Define Binding and
Profile in Glossary Owner: Jeff Hodges Status: Open Still open. #0144: Explain optional
subject decision Owner: Eve Maler Status: Open Still open. Deferred to post
SAML 2.0 #0125: Propose language to
explain that AuthNResponse may contain attribute statements Owner: Prateek Mishra Status: Open Still open. #0123: Obtain MIME type
registration for HTTP lookup of SAML Owner: Jeff Hodges Status: Open * Scott – we need to
do one for metadata as well. Roll the metadata one into this AI. Still open. 5. Any other business? a. MaryAnn –
what’s the status of the Thomas Gross paper response? * Prateek – the draft
was published by John Linn and we are in a review period at this time. b. Hal – drawing
attention to the new proposed OASIS IPR policy. Folks need to look at
this. * This is a fairly
substantial rework. * Formal part of the call adjourned. ------------------------------------ Attendance of Voting Members Hal Lockhart BEA
Ron Monzillo Sun Microsystems
Ron Monzillo Sun Microsystems - Requested
prospective status 7/12/2004 ------------------------------ Focus call (minutes by Rob) Attendees: Steve A, Jeff H, Irving R, RL Bob, Scott
C, Ari K, Darren P, Rob P, Nick R, Dana K. * Discussion of Scott – note that right column for LECP is for
the “client” side. Prateek – is this roughly where we want to go
after augmenting with the various types of responders. Scott – note there is an ambiguity w.r.t.
metadata – is it MTI? There was a presumption in Scott – You could only test dynamic metadata
exchange. It should probably be a separate box, but don’t feel it should
be MTI. Scott – feels that the philosophical approach
of having graded levels of conformance is useful. The issue is what is
the minimal set for SP Basic, etc. Nick – The intent is that an SP has fewer
constraints in order to be conformant. Prateek – Sounds like the proposal is to start
with the Liberty SCR columns, add the SAML Responder columns, and change it as
is negotiated by the TC. Scott – Note that the one-time identifier and
the affiliations may need to be captured in a different way. Prateek – Concerned that an SP that
doesn’t maintain any persistence store MUST implement the
RegisterNameIdentifier. Scott – but it just means that you just have
to properly consume the message. If you don’t have a persistence
store, then your interpretation of the message is constrained to your
session-based user interaction. [Rob had do drop off the call. Remaining minutes
provided by Prateek] Continuted discussion around role of Name Management
Protocols (e.g., RNI) and SP Basic. Prateek: Suppose we have a simple-minded SP that has
a fixed list of SAML authorities, certificates and name
identifiers that it accepts. It has no ability to write into persistent state.
How can it implement RNI? Scott: RNI has appropriate conditionalities built
into its protocol processing rules. Weak SP need not implement persistence but may still
be able to qualify for SP Basic conformance. Prateek: concern that conformance suite will not be
able to distinguish between a stateful SP and one without state. Note that this is different from the issue of maintaining
client-side session state. Nick: current discussion within Scott: What about encryption? Suggested that it be
built into the individual profile and mentioned in the implementation matrix found in the current
conformance document. Thinkhs that it should not be exposed at the level
of conformance. Even you implement a certain profile than it is MTI
to implement supported encryption/decryption of
elements/assertions. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]