Friday Afternoon minutes will be out soon.
Minutes of SAML 2.0 F2F #2
Wed Oct 22
Jahan: Wed PM
John Hughes: Thu AM
Bob Morgan: Thu PM
Michael McIntosh: Fri AM
Rebekah Lepro: Fri PM
Steve Anderson took attendance; Quorum
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
Rob asked for any other issues/items. No
1:45-2:45 -- Session
Support (W1) - John Kemp cannot attend, so we need a presenter
2:45-3:45 -- Identity
Federation (W2) - Scott Cantor, John Linn
3:45-4:00 -- Break
4:00-4:30 -- SSO with
Attribute Exchange (W2a), Prateek Mishra
9:00-9:30 -- Enhanced
Client Profiles (W5a), Frederick Hirsh
9:30-10:00 -- SSO Profile
Enhancements (W-5), Prateek Mishra
10:00-11:00 -- Metadata and
Exchange Protocol (W-3), Jahan Moreh
11:00-11:15 -- Break
11:15-12:00 -- Profile
Enhancements for Meta-data (W-4), Jahan Moreh
12:00-2:00 -- Extended lunch
break (includes WS-I Security Profile WG Call)
Authorization Decision Reconciliation, (W-28c), Hal Lockhart
Credential Collector Proposal (W-17), Tim Moses
4:00-4:15 -- Break
4:15-5:15 -- Kerberos
Support (W-25), John Hughes
9:00-10:15 -- Editorial
Issues and Next Steps, Eve Maler
10:15-11:15 -- Attribute Decision
Reconciliation, (W-28a), Rebekah Lepro
11:15-11:30 -- Break
11:30-12:00 -- IssuerName
Enhancement, (W-28d), Rebekah Lepro
12:00-12:30 -- Lunch
12:30-1:30 -- Authentication
Context, (W-8), Do we have an owner or presentor?
Delegation and Intermediaries (W-15), Bob Morgan, Jeff Hodges, Ron
2:30-2:45 -- Break
2:45-3:30 -- Baseline
Attribute Namespaces, (W-21), Bob Morgan
3:30-4:00 -- Discovery
Protocol, (W-7), Scott Cantor
Document: Section 3.6,
4:00-5:00 -- Issues List for SAML
2.0, Eve Maler
Session Support (W1) Document:
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
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
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
Hal: seems difficult to participate in a
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
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
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
Group: we should use the definition in the
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
Hal: is the definition of "Service" really
Scott: don't know even if John K. really uses this
Steve A: I have proposed alternative definition to
clarify "time out" period. Also have commented on differences between time out
Mike B: it appears that Session and Shared Session are
identical. Also, the distinction between timeout and idle timeout is not
Scott: it is up to "Session Participants" to determine
what constitutes inactivity
Anthony: I assume that anyone can become a "Session
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
Rob: we should look at the use case from
Fredrick: are we suggesting that the sessions and
sub-sessions are association with a group.
Jahan: Are sub-session tied to the parent
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
Hal: hard to see if you can shared session without
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
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
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
Anthony: is a session in any way related to the
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
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
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
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
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
Anthony: can the user utilize the pseudo name as an
Scott: No. The purpose behind the requirement is to
dynamically create the association between the user's identities at multiple
Anthony: can we have pseudo names without account
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
Anthony: is this an optional thing?
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
Scott: yes, my proposal is to use XML
Scott continued to discuss Section 3 (use
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
Section 3.3 Name Identifier Change
Section 3.4 Provider terminates
Section 3.5 Service providers
without communicating without identity federation
Scott continued with Section 4: Candidate
The big change has nothing to do with federation but
has everything to do with encryption.
Section 4.1. Revision to
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
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
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
Anthony: can we specify other name
John H. what about Kerberos and DCE name
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
Anthony: we need to support the case of "one time"
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
Eve: are we trying to address to backward
Bob: that's certainly a goal.
Eve: major versions are opportunities to make design
ISSUE: Need to define Name Identifier for other
4:55-5:30 -- SSO Profile Enhacements (W-5),
ISSUE: need to determine if we replace the
ISSUE: we need to make sure that the
<AuthNRequest> encoding rules are clearly defined.
ISSUE: requirements for signing requests should be
ACTION: Define SAML <AuthNRequest> (it could
be derived from LA 1.1)
ACTION: Anthony to document use case for
Prateek presented LA 1.1 proposal analysis. The basic
question is should we go ahead and replace SAML browser profiles with the LA
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
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
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
Meeting adjourned at
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
Rob B: will have to rename the
Presented LECP Flow from IDP, via LEC to
Eve: liberty considering other AuthnRequest
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
Frederick: need release of the
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
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
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),
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
Scott: tending to use the term "account
linking". In the liberty doc "federation" tends to mean account
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
Scott: distinguish intermediaries
Simon: Also need to look at privacy
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
Anthony: just an augmentation of this use
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),
Mainly to do with use of Meta-Data rather than
Schema: draft in repository:
sstc-saml-metadata-2.0-draft-00. Based on liberty 1.1
2 categories: service protocol and
Scott: also add 3rd category: trust
Scott: would call service protocol metadata as
Jahan: More work on: terminology, handle new
Prateek: what is the scope of this
Scott: to address use cases that SAML needs
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
Scott: needs to be able to encompass all roles.
Need it encompass core and to foster inter-operability - make it
Scott: new profiles could define their own
Anthony: should the request send
Jahan: this does not talk about the protocol to pass
Scott: do we talk about publishing and getting
it, or having a rich metadata protocol.
Jahan: this is probably what the discovery protocol
Scott: believes should use simple mechanism:
e.g. http GET
What about trust of metadata
Scott: what about signing of
No requirement to sign it.
Tim M: shouldn't each endpoint have their own signed
Irving: that is probably the most common
Rob B. We haven't actually discussed the use
cases of metadata.
Scott: need to provide a wrapper so can define
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
Scott: but down to the IdP to define what they
Jahan: let the underling PKI infrastructure to deal
with revocation mechanisms
Hal: the keyInfo could be a
Charles: Where is the definition for defining
the SOAP channel, what defines the type of authentication?
Rob P: need to be able to define
Irving: this may evolve to be WSDL
Irving: could we write metadata as SAML
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
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
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
Simon: will these protocols be
Irving: DDDS will probably not be taken
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
sstc-saml-MetadatainBindings-20-draft-*. Uses SAML 1.1 B&P doc as
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"
2:00-3:00 -- Authorization Decision
Reconciliation, (W-28c), Hal Lockhart
Hal: some advancement since last
at that F2F XACML TC proposed a new
issue: status layering, clarifying what SAML and
XACML 2.0 will fix this by making element optional in Response
issue: which TC/schema
new schema will be in SAML namespace
Irving: proposing approach that will mean no refs to XACML
issue: attribute naming: topic will be
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
Hal: condition is more general, obligation is just result of authz
Irving: need to make guidance clear
Hal: use of conditions isn't clear to start with
Simon: obligations don't require "understanding" as conditions
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
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
Hal: not SAML schema?
many: right, not SAML
Eve: main thing is to make sure one group is doing it, not
Prateek: so shouldn't SAML deprecate existing
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
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
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
AI: chairs (or Prateek) will collect information on use of existing SAML
authz decision statement, to support the decision about possible
deprecation of this
AI: all presenters please upload presentations to OASIS
AI: Rob P will check to make sure that all TC materials are available to
3:00-4:00 -- Credential Collector Proposal
(W-17), Tim Moses
3 projects that have been separate, propose to
consider them as one activity
old TC item of pass-through
system entity (client) authenticates to authn-authority via
this intermediary is the "credentials collector"
in shared-secret case, intermediary will end up knowing the secret
Liberty SASL authentication for SOAP proposal (Jeff
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
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
Tim: protocol between authn authority and client
so that authentication can happen
authentication assertion be returned to client/intermediary
along with shared secret
Scott: important to tie this to some concrete
Tim: this could be SOAP client and SOAP gateway
Tim: how should SOAP/SAML work be
Bob: doesn't seem like SSTC work item, could be
AI: Tim will work with Jeff on concluding SOAP/SAML
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
4:00-4:15 -- Break
4:15-5:15 -- Kerberos Support (W-25), John
Proposing credential conversion
"conversion request" message includes input cred, desired output
"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
Rob: what's the work item
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
core, bindings, schema docs now cast as 2.0
deprecated items removed
other docs coming along ...
document editors relying on Work Item owners to
new issues need to be captured, owned by someone
terminology changes to be done by
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:
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
proposal describes requirements for any URL scheme,
http as an example
TC should submit request for "application/saml+xml"
since this is way to get application semantics
RFC 3023 specifies handling of XML media types
Irving: can't we just use
Scott: not clear if it's in use. SOAP uses
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
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
Eve: seems like good idea, prefer to put at the
9:00-9:45 -- Plan for next f2f; Process for
use case prioritization
Started at 9:15 - Prateek (Chair)
Next F2F Meeting in Early December
Can we be productive?
Hope we can look at first drafts of solution proposals
Work of technical details
XML 2003 December 9-12 (Philadelphia).
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
Freeze Specs by end of Q104
Use Cases (UCs)
Prateek: How do we select those that will be in SAML
Discussion about options for processing
Eve: Recommends Quaker Poll (rank top
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
Tony: UCs will have to be in by Oct
Rob: Is that unreasonable?
Tony: We will try, may not have time for full
Prateek: Revised Proposal: Identify by Oct 28 (just a
list), complete details by Nov 11.
Bob: Once we have UCs what is the
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
Rebekah: Major versions are our only chance to fix
Bob: Maintain the domain model, don't throw everything
Eve: Some Principles (Will send to secretary to be
included in Minutes)
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
Minimally invasive to the 1.x design
Overall backwards compatibility
Maximally elegant design
9:45-10:45 -- Attribute Decision Reconciliation,
(W-28a), Rebekah Lepro
Attribute identifier merges attribute name and
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
Can we provide for wildcard requests with single
Discussion about methods for wildcarding all
attributes within a namespace
Scott: objects to assigning semantics to attribute
Discussion about attribute namespace
Rebekah: Email from Bob in the
-How do you represent X.500, URI,
-The attribute namespace represents the
type/style/classification/syntax/format of attribute
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
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
Eve: Doesn't want to call these "format URIs"
Discussion about various ways namespaces are
Prateek: Proposal is retain what we have in SAML 1.1
Scott: ... a convention to retain structure of XACML
Prateek: Would the SAML spec then point to several
taxonomies like SAML?
Rebekah: It doesn't need to say anything about any
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
Hal: namespace means - domain in which name is
Prateek: there is both format/class and
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
Rebekah: doesn't think the problems are unique to
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
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
ACTION: Rob - to publish UC for taxonomy for naming
ACTION: Prateek - to publish UC taxonomy for naming
ACTION Scott - to publish UC taxonomy for naming
10:45-11:00 -- Break
11:00-11:30 -- IssuerName Enhancement, (W-28d), Rebekah
How can an RP distinguish between several different
standard formats of an issuer string?
How can we qualify element to provide attribute
Value scope not name scope (ala XML
Scott: Scope is a property of the value of the
Discussion about whether scope is part of value, or
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
Bob: How many decorations are
Scott: If we don't tighten up what we've done any
further, the XACML work item might be to establish
Simon: How would you do this for XACML
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
Scott: I believe Tim Berners-Lee would feel that two
URIs that are identical had better represent the same
Rebekah: The basic question is whether scope is
considered an identifying property.
Attribute Datatype (still
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?
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
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
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
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
X.500/LDAP-defined attributes in SAML attribute
Desire to reuse definitions as easily as
Build SAML AAs with connectors to X.500/LDAP
directories as stores
May want to turn off strict checking of
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
Bob: Write up will focus on specifics of the desired
Prateek: Next step is issuance of the document and
Scott: When we move to interop, it will revolve around
12:30-13:15 -- Lunch