← Prev in month
← Prev in thread
SSTC f2f minutes Wed afternoon thru Friday Morning
Title: OASIS SSTC F2F October 22-24, 2003, raw notes Friday Afternoon minutes will be out soon. Minutes of SAML 2.0 F2F #2 Wed Oct 22 2003 Notes takers: Jahan: Wed PM John Hughes: Thu AM Bob Morgan: Thu PM Michael McIntosh: Fri AM Rebekah Lepro: Fri PM Preliminaries, Roll-Call * Steve Anderson took attendance; Quorum achieved * Prateek reviewed agenda. Agenda favors presenter with published drafts/work items. Some agenda items were changed due to various flight commitments. Updated agenda appears below. * Rob iterated that we need to stay focus on technical issues. * Rob asked for any other issues/items. No issues/items Updated Agenda Wednesday, October 22: 1:30-1:45 -- Preliminaries, Roll-Call 1:45-2:45 -- Session Support (W1) - John Kemp cannot attend, so we need a presenter Document: http://www.oasis-open.org/apps/org/workgroup/security/download.php/3659/draft-sstc-session-management-02.pdf 2:45-3:45 -- Identity Federation (W2) - Scott Cantor, John Linn Document: http://www.oasis-open.org/apps/org/workgroup/security/download.php/3820/draft-sstc-nameid-03.pdf 3:45-4:00 -- Break 4:00-4:30 -- SSO with Attribute Exchange (W2a), Prateek Mishra Document: http://www.oasis-open.org/apps/org/workgroup/security/download.php/3893/sstc-bindings-extensions-03.pdf Thursday, October 23: 9:00-9:30 -- Enhanced Client Profiles (W5a), Frederick Hirsh Document: http://www.oasis-open.org/apps/org/workgroup/security/download.php/3802/03-09-18-lecp-proposal-v4.pdf 9:30-10:00 -- SSO Profile Enhancements (W-5), Prateek Mishra Document: http://lists.oasis-open.org/archives/security-services/200310/msg00091.html 10:00-11:00 -- Metadata and Exchange Protocol (W-3), Jahan Moreh Document: http://www.oasis-open.org/apps/org/workgroup/security/download.php/3695/sstc-saml-MetadataDiscoveryProtocols-2.0-draft-00.pdf 11:00-11:15 -- Break 11:15-12:00 -- Profile Enhancements for Meta-data (W-4), Jahan Moreh Document: http://www.oasis-open.org/apps/org/workgroup/security/download.php/3697/sstc-saml-MetadataInBindings-2.0-draft-00.pdf 12:00-2:00 -- Extended lunch break (includes WS-I Security Profile WG Call) 2:00-3:00 -- Authorization Decision Reconciliation, (W-28c), Hal Lockhart Document: http://lists.oasis-open.org/archives/security-services/200310/msg00049.html 3:00-4:00 -- Credential Collector Proposal (W-17), Tim Moses Document: http://lists.oasis-open.org/archives/security-services/200309/msg00106.html 4:00-4:15 -- Break 4:15-5:15 -- Kerberos Support (W-25), John Hughes Document: http://www.oasis-open.org/apps/org/workgroup/security/download.php/3760/draft-sstc-use-kerberos-01.pdf Friday, October 24: 9:00-10:15 -- Editorial Issues and Next Steps, Eve Maler 10:15-11:15 -- Attribute Decision Reconciliation, (W-28a), Rebekah Lepro Document: http://www.oasis-open.org/apps/org/workgroup/security/download.php/3666/28b-draft-solution-0.1.pd 11:15-11:30 -- Break 11:30-12:00 -- IssuerName Enhancement, (W-28d), Rebekah Lepro Document: http://www.oasis-open.org/apps/org/workgroup/security/download.php/3667/28d-draft-solution-0.1.pdf 12:00-12:30 -- Lunch 12:30-1:30 -- Authentication Context, (W-8), Do we have an owner or presentor? Document: http://www.oasis-open.org/committees/download.php/3899/liberty-architecture-authentication-context-v1.1.pdf 1:30-2:30 -- Delegation and Intermediaries (W-15), Bob Morgan, Jeff Hodges, Ron Monzillo Document: TBA 2:30-2:45 -- Break 2:45-3:30 -- Baseline Attribute Namespaces, (W-21), Bob Morgan Document: TBA 3:30-4:00 -- Discovery Protocol, (W-7), Scott Cantor Document: Section 3.6, http://www.oasis-open.org/committees/download.php/3898/liberty-architecture-bindings-profiles-v1.1.pdf 4:00-5:00 -- Issues List for SAML 2.0, Eve Maler Document: http://www.oasis-open.org/apps/org/workgroup/security/download.php/3826/sstc-saml-2.0-issues-draft-01.pdf 1:45-2:45 -- Session Support (W1) Document: http://www.oasis-open.org/apps/org/workgroup/security/download.php/3659/draft-sstc-session-management-02.pdf * Scott replaced John Kemp as lead presenter. * ACTION: SSTC to direct John Kemp to do a gap analysis based on Liberty's spec. Additional requirements : Idle time out, Mike B. requirements (multiple sessions), Anothony's use case * ACTION: Anthony to provide use case. * ACTION: Mike Beach to provide use case * ACTION: John Kemp to reconcile definitions with SAML glossary. Scott: The current ID-FF 1 and 2 work does not really pretend to address session work. There is a notion of logout and also a notion of re-authenticate. However, these is no true notion of the session. Bottom line: we do not have any true session support. John Kemp tried to figure out if session can be decoupled from authentication. E.g., one could ask for a session without authenticating. Such a work would require assertions and statements that tie back to a session. John K. has done some preliminary work to scope this effort. John K. also has done some technical work around schema and messages for requesting sessions. Prateek: SAML 1.x has no notion of session. But Liberty 1.1 has some notion of a session. Scott: yes. However, Liberty 1.1's notion of session is just the idea of shared data between IDP and ISP. Thinks we can take Liberty protocol and polish it without pushing it to a whole new way of doing session. Hal: it is important to settle the assurance requirements for sessions. I would characterize Liberty logout as a "friendly hint". The question is how strict is the semantics of logout and the amount of tracking required by the session authority. Scott: is it required to be compliant with the local application session management (e.g., J2EE session cookie). Bob M: even if the logout data is given to the "session authority" that data must be propagated to the application. Hal: seems difficult to participate in a "logout". Mike B: We look at "agents" that do session management. It is difficult without impacting the application for the agent to "terminate" the application's session. Group: not all applications will be able to participate in a session. Bottom line is that if an application wants to participate in a session then it must accept certain protocols in terms of contacting a session authority or agree to be contacted by a session authority. Hal: I think we will define messages that record the state transition of a session and the implementation of the state transition is up to the application. Prateek: let's take a look at the requirements in John K.'s document and see if we can comment on it. Rob: I believe we can get a simple set of session management messages/protocols that can satisfy some basic requirements. Scott went through Section 1.2 (Definition) of John K's document. Scott emphasized again the requirements for separating authentication from session. Hal: is there a case where you would ask a session without an authentication. Scott: one way of thinking about it is that there is an implicit requirement for authentication. I.e., a session would be established only if the user is authenticated. However, this is just one way of looking at it. Eve: we already have a definition for Session in the Glossary (see SAML 1.1 glossary). We also have definitions for "login" and "logon". Group: we should use the definition in the Glossary. Greg Whitehead: there is a use case for local session that collects state and authenticates later. Scott: continuing with the Definition section: Logout is fairly clear, especially if we agree on the definition of a Session. Hal: is the definition of "Service" really needed? Scott: don't know even if John K. really uses this later on. Steve A: I have proposed alternative definition to clarify "time out" period. Also have commented on differences between time out and logout. Mike B: it appears that Session and Shared Session are identical. Also, the distinction between timeout and idle timeout is not clear. Scott: it is up to "Session Participants" to determine what constitutes inactivity Anthony: I assume that anyone can become a "Session Authority". Hal: the intention is that you need to be trusted and follow the protocol. Anthony: we have a requirement to have sub sessions in a publish/subscribe model. Bob M: does this imply "interactive sessions"? Rob: we should look at the use case from Tony. Fredrick: are we suggesting that the sessions and sub-sessions are association with a group. Jahan: Are sub-session tied to the parent session? Anthony: if the parent session is killed the sub-sessions go away, but not the other way around. Rob: we should articulate the use case for sessions/sub-session Hal: hard to see if you can shared session without single signon Mike B: the use case that we would have is to consolidate authentication mechanism. Scott and Bob: we need to articulate the use case for using an authentication authority for establishing a local session while opting out of single sign on. Mike B: we have a clear requirement for separating sessions (e.g., a group of applications in a business session from a group of application in a personal session). However, we would want to use the same authentication authority. Jahan: The fact that we are using the same authentication authority is not important. Rob: it is important in the sense that we want to ensure that if you have authenticated with the authority, you do not automatically get authenticated across the two sets of sessions. Rob: process check. We have allocated an hour. We need to either wrap this up or continue. Decided to continue. Prateek: how important is that we have a richer session than Liberty 1.1. John K. has asked for direction from us. Anthony: is a session in any way related to the authentication context? Scott: don't think so. Hal: what is Liberty logout tied to? Scott: It is IDP-centric in that it is based on the IDP's notion of the session ID. Eve: we started this discussion by noting that we should decouple Authentication from Session. We should keep this decoupling. Prateek: should we direct John to use the Liberty model and nothing beyond it? Greg: note that in Liberty there is no notion of a central authority that keeps track of sessions. Rob: we can continue this work in SAML 2.x. I.e. we need not finish all the work in 2.0. Hal: the original idea was that if the user interacts with any local session then the user maintains activity. Fredrick: can we ask John K. to provide multiple levels of complexity and then we would decide? Prateek: He has done it in some ways. The first is to polish Liberty's. The second is to introduce the notion of idle time and session authority. 2:45-3:45 -- Identity Federation (W2) - Scott Cantor, John Linn Document: http://www.oasis-open.org/apps/org/workgroup/security/download.php/3820/draft-sstc-nameid-04.pdf * ISSUE: should we/how would we allow SAML 2.0 messages to carry SAML 1.1 messages? * ACTION: Anthony to write use case for "one time identifier'. Scott presented Candidate name identifier profiles and management for SAML 2.0. Basic set of requirements come from Liberty and Shib. Anthony: are the ID-FF references to 1.1 or 1.2. Can you please indicate which are 1.2 requirements. Scott: Section 2.1 (affiliation) is ID-FF 1.2 work. Name identifier encryption (Section 2.5) also 1.2. Everything else is 1.1. Scott continuing on with requirement section (Section 2): a principal is identified by a triple consisting of a pair of identifiers for the systems in the federation and the pseudo name of the entity. Anthony: can the user utilize the pseudo name as an identity? Scott: No. The purpose behind the requirement is to dynamically create the association between the user's identities at multiple providers. Anthony: can we have pseudo names without account linking. Scott: yes. Anthony: is it the case that a pseudo name can serve as a name identifier, or some other identifier, or nothing. Scott: yes, this is between providers. Anthony: is this an optional thing? Scott: yes. Scott: another key requirement covers affiliation (again, this is from Liberty 1.2). The idea is to allow the same identity to be shared across multiple (affiliated) providers. Anthony: do you have a requirement that one IDP can create a pseudo name and establish it with another IDP? Scott: you can, but the first IDP is really acting as a Service Provider. Hal: we can use XML encryption to satisfy Name Identifier Encryption. Scott: yes, my proposal is to use XML encryption. Scott continued to discuss Section 3 (use cases). Sections 3.1 Service Provider Initiates Identity Federation Anthony: does this support the case of an identity that does not have an account? Scott: yes, we can do this by providing dynamic accounts. It is also not necessary that you have authenticated with the service provider before you can federate. Sections 3.2 Identity Provider Initiates Identity Federation No discussion Section 3.3 Name Identifier Change Request No discussion Section 3.4 Provider terminates identity federation No discussion Section 3.5 Service providers without communicating without identity federation No discussion Scott continued with Section 4: Candidate Mechanisms The big change has nothing to do with federation but has everything to do with encryption. Section 4.1. Revision to <NameIdentifier> Element. It is worth considering renaming <Format>. Proposing to add a new name qualifier where the identifier can be further qualified as that of the Service Provider or the Affiliation Provider. Bhavna: we should address the relationship between NotBefore element here and how it relates to the assertion. Eve: are we proposing that in 2.0 we overhaul NameIdentifier? Scott: yes. Eve: can we ensure that users can continue to use the non-federated cases we support today? Scott: yes, this is the purpose Section 4.2 Revision to format identifiers Anthony: can we specify other name spaces? John H. what about Kerberos and DCE name spaces? Scott: we probably want to include other name spaces. Anthony: One Time Identifier: does it mean that the identifier is a one time usage? Scott: it is simply a qualifier that indicates that the identifier is transient. Rob: this should be called "transient" or "non persistent". Anthony: we need to support the case of "one time" identity? Rob: we need to define a use case that is consistent with "one time" identity. Section 4.4 Proposed Protocol and Schema for Identifier Management Rebekah: Liberty 1.1 uses SAML 1.0, how do we deal with that going forward? Scott: we will derive from Liberty 1.x and then create SAML 2.0. Scott thinks Relay State should be defined as part of bindings not as part of the base protocol. Bob: what is the transition path from this proposal to actual SAML 2.0 schema changes? Scott: the document does not address this? Eve: are we trying to address to backward compatibility? Bob: that's certainly a goal. Eve: major versions are opportunities to make design changes. ISSUE: Need to define Name Identifier for other authority types. 4:55-5:30 -- SSO Profile Enhacements (W-5), Prateek Mishra Document: http://www.oasis-open.org/archives/security-services/200310/msg00162.html * ISSUE: need to determine if we replace the existing profiles. * ISSUE: we need to make sure that the <AuthNRequest> encoding rules are clearly defined. * ISSUE: requirements for signing requests should be considered. * ACTION: Define SAML <AuthNRequest> (it could be derived from LA 1.1) * ACTION: Anthony to document use case for SOAP/based profile. Prateek presented LA 1.1 proposal analysis. The basic question is should we go ahead and replace SAML browser profiles with the LA browser profiles. Prateek: LA and SAML have different requirements for signing assertions and responses. Prateek: is there an interest in relaxing the requirements for signing requests? Scott: we need to determine the motivation/requirement for signing. Rob: do we replace the existing profiles or do we keep existing profiles and add these new profiles? Scott: LA supports both destination-first and source-first flows. It does not appear that we need to support the older profiles. However, this is subject to requirements for signing. Anthony: How do we take a browser profile and have it talk to a SOAP servers. Hal: would we prefer not to do this? Prateek: this is characterized as a distinct profile. Meeting adjourned at 5:35 pm. ---------------------------------------------------------------------------------------------------- Thursday, October 23: 9:00-9:30 -- Enhanced Client Profiles (W5a), Frederick Hirsh Intent to add an additional liberty profile (LCEP - Liberty-Enabled Client and proxy Profile). Use case is with mobile user accessing web site for service. Copes with Limited or no cookie support and copes with URL length limitations. Minimal impact on service providers. Impact: new LECP Profile. HTTP response with AuthnRequest. Rob B: will have to rename the profile. Presented LECP Flow from IDP, via LEC to SP. Eve: liberty considering other AuthnRequest messages? Scott: yes, others been considered. All derived from the abstract request/response messages AuthRequest - Liberty 11 authn request. Defines Provider ID, Provider Name, IDPList and ISPassive. Anthony: based upon Liberty 1.1? Frederick: based on 1.1. but 1.2 has some schema changes - not to sure what to do with the new schema changes Anthony: what about addressing man in the middle attacks. Frederick: need release of the document/paper Anthony: As soon as conference is held can release Man in Middle Attacks paper - available in Dec Next Steps: define LECP Profile and decide what to do on the schema changes Irving: does the protocol define which bits of liberty are used Frederick: yes - there are options that define extra bits that can be used. Fredrick: geared around authn and not using SOAP in interacting with the client Scott: Liberty POST profile uses meta data to define where the assertion is sent, whilst SAML allows the redirector to define it. Anthony: how does the authn context get wrapped Scott: separate. LECP just wraps up the existing structure, doesn't modify it. Frederick: what are next steps? Scott: better use of time to focus on the core SSO profiles and then derive the LCEP profile from them. Bob Morgan: perhaps develop some more use cases, e.g. web dev clients. Scott: profile also to do with intelligent devices with dumb service provider * ISSUE - SOAP 1.1 vs SOAP1.2 * ISSUE - schema, vs Liberty 1.1 and 1.2 · ISSUE - need to get common set of terminology that is agreed (ie. Source/destination, asserting party, service provide, identity provider * ISSUE - some overlap on feature discovery with other use cases and profiles. * ACTION: Bob Morgan - more use cases. More generic use cases, may be not involving HTTP. 9:30-10:00 -- SSO with Attribute Exchange (W2a), Prateek Mishra Once auth complies at IdP principal generates assertion and SP validates principal using assertion. Assertion contains attribute info and allows access based on attribute value. Pratreek: believer liberty spec over uses the term "federation". Scott: tending to use the term "account linking". In the liberty doc "federation" tends to mean account linking. Scott: This use case has 3 implications: 1/. Privacy preserving identifier 2/. make sure browser profile do not preclude this use case (should be a check off) 3/. Use meta data Prateek: do confidentially issues have to be addressed, e.g. Name Identifier as well as attribute names and values Scott: distinguish intermediaries Simon: Also need to look at privacy legislation Anthony: assume attributes could come from other sources than IdP and could be references? Scott: assuming maintain existing constructs should be ok, nothing in SAML precludes that. Simon: does this mean we always have to digitally sign Anthony: just an augmentation of this use case Prateek: in real world will have intermediaries, e.g. firewalls, entities within DMZ. When we analyze security properties need to take this into account * ISSUE: use of the term "Federation" * ISSUE: Impact on Name Identifier usage * ISSUE: Confidentiality issues - should be addressed in SAML 2.0 * ISSUE: may need to revisit the question whether to sign the assertion in the POST profile * ISSUE - need security analysis on all profiles in real world deployments and architectures. 10:00-11:15 -- Metadata and Exchange Protocol (W-3), Jahan Moreh Mainly to do with use of Meta-Data rather than profiles. Schema: draft in repository: sstc-saml-metadata-2.0-draft-00. Based on liberty 1.1 2 categories: service protocol and organizational metadata Scott: also add 3rd category: trust data Scott: would call service protocol metadata as operational metadata Jahan: More work on: terminology, handle new profiles Prateek: what is the scope of this proposal Scott: to address use cases that SAML needs support Eve: had discussed to not use the word meta-data - rather use "configuration" Jahan: problem is not to make it too generic and support all protocol elements - if that's the case - will never finish Scott: needs to be able to encompass all roles. Need it encompass core and to foster inter-operability - make it extensible. Scott: new profiles could define their own Meta-Data Anthony: should the request send metadata? Jahan: this does not talk about the protocol to pass around metadata Scott: do we talk about publishing and getting it, or having a rich metadata protocol. Jahan: this is probably what the discovery protocol should do. Scott: believes should use simple mechanism: e.g. http GET What about trust of metadata Scott: what about signing of metadata? No requirement to sign it. Tim M: shouldn't each endpoint have their own signed metadata Irving: that is probably the most common use case Rob B. We haven't actually discussed the use cases of metadata. Scott: need to provide a wrapper so can define multiple providers Rob P. need mechanism to protect supply of portions of metadata to different SP Scott: lots info in Liberty 1.2 metadata spec on many to many, one to many cases etc Mike B: even metadata its self could be sensitive. Scott: but down to the IdP to define what they publish Jahan: let the underling PKI infrastructure to deal with revocation mechanisms Hal: the keyInfo could be a reference Charles: Where is the definition for defining the SOAP channel, what defines the type of authentication? Rob P: need to be able to define this Irving: this may evolve to be WSDL centric Irving: could we write metadata as SAML assertions? Scott: or could we used XML schema * ISSUE: Need Use cases for meta data, re multiple IdP/documents and SPs etc · ISSUE: Should we allow multiple providers in a single document? Not prohibit it - but not concentrate on it * ISSUE: Should we allow for single providers metadata in multiple documents. * ISSUE: Need a wrapper XML element for the public key signing the assertions (<ds:KeyInfo>) within a MetaData -defining its usage * ISSUE: Need to be able to define the SOAP authentication type * ISSUE: could define WSDL definitions for some of the elements. * ISSUE: perhaps define wrapper for each profile and then define the operational data for it, * ISSUE: could metadata be defined as SAML assertions or as XML schema * ISSUE: Should we cover other trust models * ISSUE: Should SSL/TLS root certificates be included in Metadata 11:15-11:30 -- Break 11:30-12:00 - Meta Discovery and Exchange Protocol, Jahan Moreh Derives from LA 1.2 draft 08 Awaiting direction from SSTC to proceed Simon: will these protocols be stand-alone Jahan: yes Irving: DDDS will probably not be taken up Anthony: URL/URI not sufficient in web services environment, use cases where more information required Jahan: Strongly recommending HTTPS Depends on whether metadata is signed or not Proposal in sstc-saml-MetadatainBindings-20-draft-*. Uses SAML 1.1 B&P doc as starting point. * ISSUE: Need Use Cases for this * ISSUE: DDDS support to be removed * ISSUE: Discovery protocol can be HTTP/HTTPS * ISsUE: need to ensure integrity of data using either HTTPS or dsig (new note taker: RL "Bob" Morgan) 2:00-3:00 -- Authorization Decision Reconciliation, (W-28c), Hal Lockhart Document: http://lists.oasis-open.org/archives/security-services/200310/msg00049.html Hal: some advancement since last F2F at that F2F XACML TC proposed a new AuthzDecisionStatement issue: status layering, clarifying what SAML and XACML do XACML 2.0 will fix this by making element optional in Response msg issue: which TC/schema namespace new schema will be in SAML namespace Irving: proposing approach that will mean no refs to XACML within SAML issue: attribute naming: topic will be discussed later issue: where XACML obligations go when carried in SAML response ... turns out not to be an issue after all Irving: what is the difference between SAML condition and XACML obligation? Hal: condition is more general, obligation is just result of authz decision Irving: need to make guidance clear Hal: use of conditions isn't clear to start with Simon: obligations don't require "understanding" as conditions do Hal: XACML doesn't specify security considerations at RP ... Scott: adding request and response isn't the right way to extend the right way is to add a new Query and new Statement so Context info should be in Statement, not in Response Hal: yes Scott: so review of schema proposal should focus on query/statement SAML 2.0 will provide better way to do this extension Irving: this extension should be XACML schema Hal: not SAML schema? many: right, not SAML Eve: main thing is to make sure one group is doing it, not two Prateek: so shouldn't SAML deprecate existing autz-decision schema? wouldn't this mean replacing it with new stuff? Irving: just drop it from SAML, hand it to XACML Hal: this would mean no definition of authz-decision outside of XACML Prateek: is anyone using it? Sun person: we are Scott: issues are separable (doing it in XACML and deprecating current SAML authz-d) Prateek: so, ready to make formal decision on these? motion: SAML TC recommends that XACML TC derive types from SAML schema, saml:statement and samlp:query to support authorization decision, and that liaison be established to follow up on this. Passed unanimously. AI: chairs (or Prateek) will collect information on use of existing SAML authz decision statement, to support the decision about possible deprecation of this feature. AI: all presenters please upload presentations to OASIS site. AI: Rob P will check to make sure that all TC materials are available to the public. 3:00-4:00 -- Credential Collector Proposal (W-17), Tim Moses Document: http://lists.oasis-open.org/archives/security-services/200309/msg00106.html Tim: 3 projects that have been separate, propose to consider them as one activity old TC item of pass-through authentication: system entity (client) authenticates to authn-authority via intermediary this intermediary is the "credentials collector" in shared-secret case, intermediary will end up knowing the secret ... Liberty SASL authentication for SOAP proposal (Jeff Hodges): client communicates directly to authn-authority, using SOAP and authenticates using SASL mechanisms this work will be advanced with Liberty? Kerberos support (John Hughes) client is kerb-enabled, intermediary is kerb-enabled server "credentials conversion service" converts between kerb and SAML format Irving: point would be to work with non-Kerberos SP Hal: had hoped that SASL would solve the problem, but doesn't ... Bob: what is to be specified here? Tim: protocol between authn authority and client or intermediary so that authentication can happen authentication assertion be returned to client/intermediary along with shared secret Scott: important to tie this to some concrete application Tim: this could be SOAP client and SOAP gateway Tim: how should SOAP/SAML work be pursued? Bob: doesn't seem like SSTC work item, could be AI: Tim will work with Jeff on concluding SOAP/SAML work AI: Tim and John will work on reconciling work AI: Tim will add SOAP gateway use case to document Document posting discussion: Please make postings in general visible to public, by checking both boxes Please turn email notification off when posting many docs at once (Jeff ...) Please change subject line when replying to doc posting message 4:00-4:15 -- Break 4:15-5:15 -- Kerberos Support (W-25), John Hughes Document: http://www.oasis-open.org/apps/org/workgroup/security/download.php/3760/draft-sstc-use-kerberos-01.pdf John: Proposing credential conversion service "conversion request" message includes input cred, desired output type "conversion response" would provide desired cred EJB bridge server example, bridging between local/EJB env and DCE/Kerb in both directions Kerberos and SAML browser example Kerberos-enabled browser and web server (eg, IE and IIS) use Kerb authentication to get SAML assertion/artifact to use with remote site Mike: is this talking about converting user names from one form to another? Scott: that would be a different service, orthogonal to this one Rob: what's the work item here? John: defining interaction between web server and cred conversion service Rob: notion of cred converter is useful, but what's the TC work here? Eve: how do we decide among use cases that people care about, vs ones they can live with, vs ones that they want to drop? do a "Quaker poll"? Rob: would be good to enumerate use cases Friday to make this assessment 3:50-4:10 -- Editorial Issues and Next Steps, Eve Maler document status core, bindings, schema docs now cast as 2.0 drafts deprecated items removed other docs coming along ... document editors relying on Work Item owners to propose changes new issues need to be captured, owned by someone terminology changes to be done by editors would like to fix poor wording in 1.1 docs editors will propose changes to TC AI: Eve will publish new OpenOffice-based template AI: Prateek to "freshen" Conformance doc AI: Frederick to "freshen" security/privacy doc AI: Eve will propose editorial changes to core doc AI: Eve will add to FAQ (after November) AI: Eve will send out filenaming proposal to list Scott: URI references to assertions (doc: draft-sstc-assertion-uri-01.pdf) WSS security SAML token profile has way of referring to SAML assertions but uses deprecated schema element (authority binding) but WSS use case seems pretty clear "to be web-friendly you should be URL-friendly" proposal describes requirements for any URL scheme, http as an example TC should submit request for "application/saml+xml" media type since this is way to get application semantics RFC 3023 specifies handling of XML media types Irving: can't we just use application/xml? Scott: not clear if it's in use. SOAP uses application/soap+xml use fragment identifiers? only works if they're defined in that media type is this new binding? no, doesn't use SAML protocol, so not a binding of that it's a new protocol probably should live in core doc, alongside current protocol supposed to work forever? no, but this is general question about security token references Scott: proposes requirement that if assertion is accessible via SAML protocol using assertion-id request MUST also be available via http: GET sense seems to be that SHOULD would be better AI: Scott will draft request to IANA for media type AI: Scott will write text for this new protocol Simon: can glossary be put into core doc? Eve: seems like good idea, prefer to put at the end 9:00-9:45 -- Plan for next f2f; Process for use case prioritization Started at 9:15 - Prateek (Chair) Planning Next F2F Meeting in Early December Can we be productive? Hope we can look at first drafts of solution proposals Work of technical details Review Constraints Thanksgiving XML 2003 December 9-12 (Philadelphia). Holidays Where/When? Eve/Sun and/or Hal/BEA can host in Boston Tony/IBM can host in Austin Decision: Target Week of January 12th, not in December, ballot to follow. Freeze Specs by end of Q104 Use Cases (UCs) Prateek: How do we select those that will be in SAML 2.0 Discussion about options for processing UCs Eve: Recommends Quaker Poll (rank top five) Prateek: In order to get to committee draft state by end of Q1, we have to have clarity by January. Eve: We need to close UCs sooner Prateek: Initial Proposal: Next conf call (Oct 28), we announce the UCs (Prateek will summarize those from this meeting and new ones from this meeting) that will be in SAML 2.0, we will vote November 11. Tony: UCs will have to be in by Oct 28? Rob: Is that unreasonable? Tony: We will try, may not have time for full detail. Prateek: Revised Proposal: Identify by Oct 28 (just a list), complete details by Nov 11. Bob: Once we have UCs what is the process? Rob: Prioritization. Discussion about ranking process since we might not have time for all of them Eve: expressed concern about changing the existing design due to more work involved Rob: Schedule is very important, beyond that we need to get the right set of stuff done backwards compatibility is less important Rebekah: Major versions are our only chance to fix things Bob: Maintain the domain model, don't throw everything away. Eve: Some Principles (Will send to secretary to be included in Minutes) Design principles, roughly ranked by order: - Must meet the schedule - (Equally) Must meet the accepted use cases - Retain the existing domain model (i.e., restructuring not acceptable; additions are acceptable) - Clean versioning path from 1.x to 2.0 and beyond - Selective backwards compatibility where it doesn't conflict with other goals Design non-principles: - Minimally invasive to the 1.x design - Overall backwards compatibility - Maximally elegant design 9:45-10:45 -- Attribute Decision Reconciliation, (W-28a), Rebekah Lepro Document: http://www.oasis-open.org/apps/org/workgroup/security/download.php/3666/28b-draft-solution-.1.pd Attribute identifier merges attribute name and namespace. Attribute datatype describes value. How do we collapse name and namespace into single identifier like XACML? How do we split single URI into name and namespace? Can we provide for wildcard requests with single identifier? Discussion about methods for wildcarding all attributes within a namespace Scott: objects to assigning semantics to attribute namespaces. Discussion about attribute namespace usage Rebekah: Email from Bob in the archive: -How do you represent X.500, URI, etc.? -The attribute namespace represents the type/style/classification/syntax/format of attribute identifier Proposal: define attribute namespace that would indicate that the attribute name contains a URI. Scott: What do we do about all the other attributes we run across? This works well for XACML. Discussion dealing with attributes from other domains Scott: the right way to solve this problem in SAML is URI based naming Irving: we need to be careful about whether we are saying that the taxonomy in the name means something more than just format. Eve: Doesn't want to call these "format URIs" namespaces Discussion about various ways namespaces are used Prateek: Proposal is retain what we have in SAML 1.1 and ... Scott: ... a convention to retain structure of XACML attributes Prateek: Would the SAML spec then point to several taxonomies like SAML? Rebekah: It doesn't need to say anything about any specific taxonomy Scott: Do we want people to continue putting other kinds of info in SAML namespaces? Bob: not wanting to remove ability to work with other attribute domains Hal: namespace means - domain in which name is unique Prateek: there is both format/class and scope Irving: afraid we will have infinite number of attribute attributes Simon: Since this is motivated by XACML UC, if we are finding difficulty with current XACML, we can look at ways of extending XACML Rebekah: doesn't think the problems are unique to XACML Irving: Perhaps these belong in separate assertions - we have so many layers where you can have multiple things, every time we add one we multiply complexity - need more simple things instead of fewer complex things SUMMARY: Proposal in 28b, discussion revolves around how to additionally classify taxonomy for naming attributes. Eve: need for additional documentation of UCs ... Scott: ... and current practice. Irving: We need to make sure when we write this down we need to be clear about what people are expected to do with these things ACTION: Rob - to publish UC for taxonomy for naming attributes ACTION: Prateek - to publish UC taxonomy for naming attributes ACTION Scott - to publish UC taxonomy for naming attributes 10:45-11:00 -- Break 11:00-11:30 -- IssuerName Enhancement, (W-28d), Rebekah Lepro Document: http://www.oasis-open.org/apps/org/workgroup/security/download.php/3667/28d-draft-solution-.1.pdf Presentation How can an RP distinguish between several different standard formats of an issuer string? How can we qualify element to provide attribute scoping? Value scope not name scope (ala XML namespace). Scott: Scope is a property of the value of the attribute. Discussion about whether scope is part of value, or separate. Bob: scope seems to apply naturally to some attribute and not to others. Rob: might the meaning of the value have different meaning depending on repository it came from? Irving: People should publish using SAML, shouldn't need to migrate values into SAML Rebekah: Need to understand the unique semantics of each attribute from different sources, need to express characteristics of property in band instead of out of band Rob: wants to group a set of attributes so I can identify where to get them from Prateek: it is this ad hoc grouping of attributes that is causing the problem. Rob: I want to know in some cases who gave that data that went into assertion Steve: As long as it is internal you may have data you key off, but from outside you don't know Rebekah: The problem is that if you later want to reason about the group of those you are pushing complexity into the name. Bob: How many decorations are enough? SUMMARY Scott: If we don't tighten up what we've done any further, the XACML work item might be to establish conventions. Simon: How would you do this for XACML today? Scott: How would XACML do it? Simon: By URI - if we have to qualify each attribute we will have to extend the language Rebekah: Attribute assertions are for sharing information - some SAML attribute assertions may be input into policy evaluation but opposite direction doesn't (always) work Scott: more advantageous if arbitrary SAML attribute assertion could be input into XACML policy assertions. Prateek: We would want any proposal to meet the test that some SAML attribute assertions must be able to be included into XACML policy assertions. Scott: I believe Tim Berners-Lee would feel that two URIs that are identical had better represent the same resource. Rebekah: The basic question is whether scope is considered an identifying property. Attribute Datatype (still 28b) We do not have a mechanism for URI defined datatypes to be associated with the attribute. XACML attributes use type information independently of presence of attribute values. Does not address potential for multiple attribute values of same attribute to carry different xsi:type. Scott: Is there a binding between type metadata and what is in identifier? Simon: No. SUMMARY: No trivial way to relate xsi:type to URI identifier. XACML types are associated with attribute designators as opposed to SAML where they are associated with values. Scott: typing is not really a strong component of the SAML specification at this point, there is no UC. Rebekah: Quoted Line 830 of SAML spec. "..." Simon: Would like a hint. Rebekah: Hint could also conflict. Prateek: What test should a proposal pass? What would be ideal? Rebekah: Datatype is required. Is there a clean way to map? Are we forcing out of band extension schemas? PROPOSAL(from 28b): SAML attribute designators should include data type information. Prateek: People should respond by email to the proposal Discussion about SAML attributes have multiple values, XACML attributes have single value element. Rebekah: Can take 28d to email Scott: We may want to discuss the issuance of assertions about metadata about a possible assertion issuer (per Bob's email on 28d) Irving: You can also have the equivalent of self signed (Issuer Making Assertions about Self) ACTION: Scott, Bob, and Irving will develop UCs for Making Assertions about Issuers of Assertions 11:30-12:00 -- Baseline Attribute Namespaces, (W-21), Bob Morgan Document: TBA Presentation X.500/LDAP-defined attributes in SAML attribute assertions Desire to reuse definitions as easily as possible Build SAML AAs with connectors to X.500/LDAP directories as stores May want to turn off strict checking of schemas Desirable would be deterministic mapping, human readable attribute names, and a sensible use of SAML attribute schema (i.e. namespace consistency with other uses) XACML approach uses document based URL naming, is human readable, but not deterministic (since same attributes are defined in many documents, would require registry anyway). OID/URN Approach can use OID URN space define in RFC3061, deterministic for all X.500/LDAP defined attributes, not human readable (but isn't translation to local name required anyway for display to humans? Can this be made an implementation requirement?) Irving: A number of LDAP schema allow you not to use OIDs in schema Short name approach since all X.500 attributes of interest will have unique short names (somtimes more than one), attribute name is just the shortname. Syntax/datatype mapping: X.500 provides syntax definition, attribute definition specifies syntax, mapping required to XML datatypes Bob: Write up will focus on specifics of the desired solution Prateek: Next step is issuance of the document and comment. Scott: When we move to interop, it will revolve around attributes. 12:30-13:15 -- Lunch
← Prev in month
← Prev in thread