OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: minor F2F minutes corrections


Title: OASIS SSTC F2F October 22-24, 2003, raw notes
Some minor corrections to the minutes, in blue - name spelling in agenda, change to one of my statements
to make it clearer what I thought I was saying
 
thanks

regards, Frederick

Frederick Hirsch
Nokia Mobile Phones


-----Original Message-----
From: ext Philpott, Robert [mailto:rphilpott@rsasecurity.com]
Sent: Monday, October 27, 2003 1:37 PM
To: 'security-services@lists.oasis-open.org'
Subject: [security-services] SSTC f2f minutes Wed afternoon thru Friday Morning

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  Hirsch 

                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.

 

 Frederick : can we ask John K. to  outline the steps of increasing complexity and then we would decide  how far to proceed ?

 

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

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]