Title: OASIS SSTC F2F October 22-24, 2003, raw notes
Attendance of voting members:
Hal Lockhart BEA
John Hughes Entegrity Solutions
Irving Reid
HP
Jason Rouault HP
Maryann Hondo IBM
Anthony
Nadalin IBM
Scott Cantor Individual
Bob Morgan
Individual
Rebekah Lepro NASA
Prateek Mishra
Netegrity
Peter Davis Neustar
Frederick Hirsch
Nokia
Charles Knouse Oblix
Steve Anderson
OpenNetwork
Eric Gravengaard Reactivity
Rob Philpott RSA
Security
Jahan Moreh Sigaba
Bhavna Bhatnagar Sun
Eve Maler Sun
Attendance of
Prospective Members or Observers:
Tim Moses
Entrust
Mike Beach Boeing
Michael McIntosh IBM
Greg Whitehead Individual
Polar Humenn Syracuse University
Ronald Jacobson Computer Associates
Simon Godik OverXeer
Membership status changes:
Tim Moses Entrust - Granted
voting status after 10/22/2003 F2F
Mike Beach Boeing - Granted voting
status after 10/22/2003 F2F
Senthil Sengodan Nokia - Requested
re-instatement after 10/14/2003 call
Paula Austel IBM - Requested
membership 10/14/2003
Phillip Hallam-Baker Verisign - Lost status due
to inactivity after 10/22/2003 F2F
Timo Skytta Nokia - Lost
prospective status due to inactivity after
10/22/2003 F2F
--
Steve Anderson
OpenNetwork
-----Original Message-----
From: Philpott, Robert
[mailto:]
Sent: Monday, October 27, 2003
1:37 PM
To:
''
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 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
