← Prev in month
← Prev in thread
Minutes from SSTC Sept 8-10 Face-to-Face meeting
Greetings everyone,
I'd like to thank everyone that was able to
make it to the first SAML V2.0 f2f meeting and for making it such a success.
Attached, you'll find the raw minutes from the
meeting. A special thanks to the minute takers!
-
Krishna
Sankar - Monday AM session
-
RL "Bob" Morgan -
Monday PM session
-
Rebekah Lepro -
Tuesday AM session
-
Charles Knouse -
Tuesday PM session
-
Eve Maler - Monday AM
Session
Votes:
9/8 - Approved minutes
of 2-Sept-03
SSTC con-call minutes as amended by Eve's email
9/10 - The group
unanimously approved Eve's motion to thank Rob Philpott and RSA for the
excellent venue for this meeting.
Action Items:
All - Anyone interested
in participating in an interop/demo at XML2003, contact Eve.
Rob - Get all
presentations posted to the list (see below)
Rob - Let OASIS
know there are no SSTC objections to providing SAML 1.1 to ITU-T.
Note from Eve: We should
probably extract all the "waiting for..." notes in the work item
document and turn them into official action items.
Re: presentations... I believe
the following is the complete list of presentations made to the TC during the
f2f. If I missed any, please let us know.
Not all slides have been
posted to the list yet.
Boeing - Mike Beach: posted
to list.
http://lists.oasis-open.org/archives/security-services/200309/msg00056.html
Fidelity - Patrick
Harding: awaiting okay from Patrick before posting
Netegrity - Leo Laferriere:
awaiting slides.
WS-Security - Ron
Monzillo: awaiting slides.
Liberty
ID-FF
- Scott Cantor, Jeff Hodges:
awaiting slides
Jeff's
flow diagram: http://lists.oasis-open.org/archives/security-services/200309/msg00039.html
Kerberos use cases -
John Hughes:
posted to list.
http://lists.oasis-open.org/archives/security-services/200309/msg00035.html
Sessions - John
Kemp: posted to list.
http://lists.oasis-open.org/archives/security-services/200309/msg00037.html
Metadata - Jahan Moreh:
posted to list.
http://www.oasis-open.org/apps/org/workgroup/security/download.php/3448/F2F_MetaData_090803.pdf
Authentication Context
- Frederick Hirsch: posted to list.
http://lists.oasis-open.org/archives/security-services/200309/msg00047.html
LECP - Frederick Hirsch:
posted to list.
http://lists.oasis-open.org/archives/security-services/200309/msg00048.html
XACML requirements -
Anne Anderson: awaiting document.
Attendance (compliments of Steve):
http://lists.oasis-open.org/archives/security-services/200309/msg00049.html
Attendance of Voting
Members:
Irving
Reid Baltimore
Hal
Lockhart BEA
Krishna
Sankar Cisco
John
Hughes Entegrity Solutions
Jason Rouault HP
Scott Cantor
Individual
Bob Morgan Individual
Rebekah Lepro NASA
Prateek Mishra Netegrity
Frederick Hirsch
Nokia
Charles Knouse Oblix
Steve
Anderson OpenNetwork
Simon Godik OverXeer
John Linn RSA
Security
Rob Philpott RSA
Security
Dipak Chopra SAP
Jahan Moreh Sigaba
Jeff
Hodges Sun
Eve Maler Sun
Phillip Hallam-Baker Verisign
Attendance of Observers or
Prospective Members:
Anthony
Nadalin IBM
Eric
Gravengaard Reactivity
Steve Whitlock Boeing
Mike Beach Boeing
Leo Laferriere Netegrity
Patrick Harding
Fidelity
Jim Lien RSA
Tejash Shah Sun
Polar Humenn
Syracuse University
Slava Kavsan
RSA
Andrew Nash RSA
Ron Monzillo Sun
Tim Moses Entrust
John
Kemp Individual
Von Welch Argonne
Natl Lab
Frank
Siebenlist Argonne Natl Lab
Anne Anderson Sun
Membership Status Changes:
Mark O'Neill Vordel -
Lost voting status due to inactivity
Anthony
Nadalin IBM - Granted voting status after F2F
Jim Lien RSA -
Requested membership 8 Sept 2003
--- Begin Message ---
From: Krishna Sankar <>
To: "Philpott, Robert" <>
Date: Wed, 10 Sep 2003 16:33:16 -0400
Title: SAML F2F Minutes 9/8/03 AM meeting
Rob,
Minutes. Actually mine is very easy ! Sorry for the delay. Got
sometime at the airport.
----------------------------------------------------------------------------
-------
> 10:00-10:15 -- Preliminaries, Roll-Call
Meeting started around 10:10. Roll call and introductions.
Approval of minutes of meeting xx/2003 was proposed by Irving and seconded
by Eve.
Call for participation in the XML2003 interop event - Contact Eve
Rob introduced the ITU publishing of SAML standards. Later during the
discussions, Rob stated that the OASIS staff would take care of the process
to publish OASIS standards in the ITU forum. Newer versions will also follow
the same process. No work needed from TC.
It was pointed out that we should have a good mechanism to collect
questions, comments and implementation experiences from the ITU community
> 10:15-12:00 -- Implementation Experience and New Use Cases
> Mike Beach, Boeing
> Patrick Harding, Fidelity
> Leo Laferriere, Netegrity
Mike, Patrick and Leo presented implementations experience, gaps of SAML 1.x
versions and wish list. We should harvest use cases and scenarios from these
presentations and augment our work items.
ACTION : Rob - get all presentations to the list or at least to the
participants.
Mike's presentation - Done
Patrick's - TBD
Leo - TBD
The group broke for lunch at around 12:15.
---------------------------------------------------------------------
-k
--- End Message ---
--- Begin Message ---
From: RL 'Bob' Morgan <>
To: "Philpott, Robert" <>
Date: Mon, 8 Sep 2003 22:51:34 -0400
Title: raw notes from SAML F2F Monday 2003-09-08, 1-5PM
Such as they are. Some of the discussion was a little hard to record ...
8^)
- RL "Bob"
---
RM: Ron Monzillo
EM: Eve Maler
JH: Jeff Hodges
PM: Prateek Mishra
RP: Rob Philpott
HL: Hal Lockhart
SC: Scott Cantor
IR: Irving Reid
WSS: SAML Token Profile, Ron Monzillo, Sun
WS-Sec signature model
authenticates signer, assures integrity of message
security token reference used to identify tokens
to satisfy key binding dependencies
data reference
SAML token profile
key identifier method used
wsse:KeyIdentifier
saml:AssertionId, saml:Binding, saml:Location
direct and URI references not used
uses wsu:id (wsu is WS-Sec utility schema)
some lack of clarity in use of various reference types ...
"key name reference" SHOULD NOT be used ...
should this be SHOULD NOT or MUST NOT ?
but key name is useful in the X.509 case?
considerations the same as in XML-DSIG,
where key name isn't interoperable
example: assertion referenced from WS-Sec header
security token reference wraps keyidentifier, which wraps assertion ID
is this just about authn statements/assertions?
no, could be any subject statement
but definitions of what, eg, attr statement means is yet to do
or is app-specific?
example: holder of key assertion referenced from keyinfo
token reference in signature refers to SAML assertion also in header
key is referenced in holder-of-key
data reference points to SOAP body or part of it
could this be an external assertion referenced by assertion ID?
seems so
note that there can be more than one subject-confirmation
is issue: can other stuff be in assertion, or not?
this is defined by application profiling this mechanism for use ...
example: sender-vouches assertion referenced from SignedInfo
data reference in SOAP header refers to Sender-Vouches assn
so is incorporated by signature ... ?
RM would like to have intermediate party get assertion via browser
use that to talk to another service as the authenticated user
request for assertion, in artifact flow, could say
"get me one that works to talk to this service"
the intermediate could ask for a special assertion for this purpose
so as not to have to extend existing artifact profile
note that confirmation applies to statement
whereas signature applies to assertion ...
RM: is the point of "artifact confirmation method"
only to say that assertion can't be passed along?
others: hmm, not necessarily
JH: can write a new profile that includes existing one (eg artifact)
and extends it
note artifact is only defined in artifact profile, not in core
PM: is there a name for this use case?
"forwarding of web-browser-profile-generated assertions"
is this easier or solved in case of POST?
POST uses bearer confirmation
not really, could have multiple confirmations ...
RM: issue is composability of SAML profiles and WSS profiles
HL: but from SAML point of view it's not just WSS but other contexts
SC: seems like use of holder-of-key and sender-vouches conf methods
have to be defined by WSS, since no existing profiles use them
but of course could apply to non-WSS contexts too ...
RM: can one request an assertion with statements with particular
confirmation method(s)?
... discussion of sender-vouches vs holder-of-key
RM: can a statement with sender-vouches conf method contain conf key?
not if that's the only conf method
RM: can entity attesting for holder-of-key statement be different
from the subject of the statement?
HL: none of the confirmation methods handle delegation
PM: can't we say the WSS-SAML profile is just abstract relationship
between entities and signtures, and avoid semantics?
IR: can use Conditions element in assertion to say
"only valid if signed by some key", for example
PM: so, this "forwarding" use case is being submitted to the TC ...
RM: there are WSS encryption issues too, but won't go into them now
RP: the ITU issue
Karl Best of OASIS said that there has been discussion with ITU about
adoption of some OASIS specs as ITU specs
ITU would take them as-is, wouldn't change
if OASIS decided to drop a spec, ITU might/should/would take it up
work for this would be done by OASIS staff, not by TCs
all succeeding versions of spec, post adoption, would be auto-accepted
benefit would be "de jure" force in some jurisdictions
also perhaps gathering of feedback from ITU participants
no objections from WG ...
Liberty ID-FF 1.2 spec and SAML, Scott Cantor
1.2 ID-FF specs are to be submitted to SSTC for consideration
drafts are available now
editorial freeze this week, new/final versions shortly thereafter
Lib specs
ID-FF "federation framework", of most interest to SSTC
ID-WSF "web services framework"
orthogonal to ID-FF for "identity-centric web services"
ID-SIS WSF "service interface specifications"
six docs in ID-FF ...
definitions
circle of trust links principals, identity providers, service providers
affiliation is group of SPs who act as a unit
in terms of namespace and privacy protection
SP can act "as itself" or as member of affiliation
management of affiliations is unspecified ...
is there an attribute authority in ID-FF? no
Liberty-enabled client (LECP):
client that knows about IdP (ie, solves "where are you from" problem)
pseudonym is identifier that is only used in bilateral relationship
between one IdP and one SP
anonymity permits service to be used without long-term identifier
(added in 1.2)
what are IdP's obligations regarding temporary ID?
only has to do so to support session
no constraints about audit-style storage of temp-id mapping info
use-case in Liberty is low-assurance services, eg location
account linking, aka account federation, aka identity federation
links identity at IdP with "account" at SP
model only covers IdP-SP linking
considerations of IdP-IdP linking not covered ...
JeffH's authentication-flow picture ...
core profiles
browser artifact (very similar to SAML)
browser POST (some differences)
note that Liberty is less restrictive about, eg, use of GET vs POST
there have been interop events, at least one public
signon and logout well-exercised
Liberty adds SP->IdP message called AuthnRequest
extension of samlp:Request
two forms: URL-encoded, via GET, considered "nasty" by some ...
base64-encoded, via POST, like SAML POST
could there also be an Artifact method in this direction?
sure, but implies request is stateful at SP
can be signed
this is entirely optional, flow doesn't require it
contents
providerID/affiliationID, ie the requester
NameIDPolicy, in 1.2 very general
eg create federation, use existing, permit anonymous, etc
ForceAuthn (must redo initial authentication)
IsPassive (don't bother user)
not necessarily well-defined with some authn methods ...
ProtocolProfile (use artifact or POST, or whatever new one)
AuthnContext (how to authenticate user, eg strength)
some relationship to Force ...
RelayState (return this blob in response)
this is where return URL is, or reference to it ...
Liberty ties response to assertion in way that SAML is not
Liberty stabilized formats before last round of SAML pre-1.0 changes
assertion is signed in response, unlike SAML
Liberty browser profile uses Audience condition for restriction
SAML uses Recipient element in Response message
LECP profile
something of an intermediary between artifact and POST profiles
relies on client knowing how to contact IdP
Liberty SSO proxying
ID-FF 1.2 adds protocol for proxying authn request to IdP
to another IdP, including non-Liberty IdPs
protocol for
limiting length of chain, returning the chain, specifying the chain
but basically just says how IdP turns around and acts as SP to an IdP
doesn't provide strongly-signed chain of assertions
just indication from nearest IdP of what happened
is this separable from rest of protocol? should be ...
EM: how are ID-FF 1.1 and 1.2 distinguished?
kept completely separate, don't send 1.2 unless know peer supports it
Liberty conventions for saml:NameIdentifier
this is recent change, in 1.1 they're just opaque strings
one-time (aka anonymous) IDs implying distinguishing format/use
"format" now used to express type of ID for SP
"NameQualifier" is provider/affiliationID of SP to whom it's being
provided, or with whom principle has affiliated
LibertySubject has two nameIdentifiers, one "Liberty" and one SAML ?
for the moment these are the same?
encrypted nameIdentifier value meets ID-WSF case
to give one SP an ID from another SP without compromising it
indicated by specific Format attribute
spec indicates how to avoid correlatable IDs
(IdP, SP, nameI) is the triple that is unique
nameI by itself isn't unique
Liberty logout: no magic ...
various ways to do it, eg redirection
can be initiated by IdP or SP
Liberty metadata, "a big part of the spec"
not just data definitions, but discovery and exchange methods (in 1.2)
classes
entity operational/policy
service endpoints
supported versions
contacts
"trust", meaning signing keys/certs
metadata resolution and retrieval
"circle of trust" is now set of metadata-exchanging entities
origin and document verification via signing
retrieval options
"well-known location"
dynamic resolution via DDDS (RFCs 3401-3405), using DNS
implies a particular trust model?
no, specifically lets this be decided at deployment time
"introduction assertion" vouches for signer of provider's metadata
via "introduction statement"
not "in Liberty 1.2" now, but might be in a followup
PM: this is a very advanced use case ...
IR: how would ordinary admins be able to write policy for this?
RL: we're looking at use cases like this, though ...
maybe the "brokering" concept is what's being supported here
Liberty authentication context
"SAML authentication method on steroids"
permit rich description of IdP's authn methods and authn instances
Lib "authentication class" is URI referring to much authn data
but this info can be included in-line in assertion
info
identification, physical protection, operational protection,
authentication mechanisms
providers and consumers can negotiate AuthnContext of assertions
avoided ranking methods in terms of strength
Liberty NameRegistration methods
register a name, deregister (ie, forget) a name
so, where should all this Liberty work go?
JH: for example, authnContext could be in separate TC
but metadata seems like it must be in SAML ...
EM:
what about versioning
and separation of profiles/features/methods into many docs?
use the standard 5-9 chunking rule? ie 5 to 9 docs?
no definite conclusion ...
we'll do Kerberos use cases first thing Tuesday morning
disposition of old deferred proposed work items, Eve M
propose to go thru items on old issues list
and permanently close those that no one wants to own
this is OK with the group
someone can always re-introduce them if desired
W-1: John Kemp will own, stays open
new W-29 created: "promised V2.0 changes"
these are deprecating/eliminating items from specs
see new doc for complete list
"B2B scenarios" e-marketplace scenario: close
other B2B still exists, Dale Moberg owns
intermediary add/delete/edit: close
no motivating use cases for this per se
runtime privacy: close
partly subsumed by pseudonymous nameIdentifier work
also covered in Security and Privacy Considerations
Hailstorm interop: close
OBE re Hailstorm per se
is this now WS-Trust/WS-Fed interop? consider this separately
nested attributes: close
no interest
negative attributes: close
no interest
discovery of authentication methods: close
will be considered as possible item to be covered by metadata work
not covered by current Liberty 1.2 metadata though
many more, Eve will send to list ...
EM: some proposed work items have tech solutions being worked on already
do these need to have use cases developed for them?
no, we won't bother doing this
--- End Message ---
20030909-02.doc
--- Begin Message ---
From: Charles Knouse <>
To: "Philpott, Robert" <>
Date: Tue, 9 Sep 2003 22:06:41 -0400
Title: Minutes for the SAML F2F Sep 9 2003 Afternoon
SAML F2F MINUTES
Sep 9, 2003 Afternoon
Jahan, Metadata (W-3 and W-4)
see presentation
- History
- Trust model
- Rob: should include signing keys as well as SSL stuff.
- Jahan: expand key info with usage information.
- Scott: in Liberty, divorced metadata from trust material, separate allows
other trust models,
- Prateek: suggestion is to have layering between metadata and trust material.
- Jahan and Scott to work together on this.
- Tony: where is the direction of metadata model?
- Jahan and Rob: specifically for browser SSO profile
- Scott: not metadata in the abstract term
- Bob: publishing of operational/ configuration data; reliable?
- Tony: similar to Grid service data
- Publication protocol
- Scott: Liberty model is dynamic: providers will get metadata and cache; use
URI or DSS
- Scott: Liberty v1.2 publication protocol not half-way: powerful and complex
- Prateek: Can we incorporate Liberty protocol?
- Scott: Peter Davis (Newstar), primary editor of Liberty metadata spec,
prepared to assist.
- Jahan: Most companies will probably take simple URI approach.
- SAML to Liberty term mapping
- Rob: Disagreed with source and destination in original SAML spec; need to
be more general than SSO profiles
- Metadata documents
- Scott: allow multiple/partial provider data in a document still an open
Liberty issue. Ok if not doing inband distribution of meta data. Separate
metadata documents for different Liberty versions.
- Jahan: consensus not to break a provider's metadata over multiple docs.
- Tony: aggregator model or separate provider URLs?
- Scott: transformation and endpoint where to get metadata for provider
- Metadata by example
- Scott: Peter changed SOAP endpoint to WSDL service definition for Liberty.
Metadata has concrete binding.
- Tony: does each service has to advertise its own metadata port? or referral?
bootstrap issue
- Scott: IdP advertises metadata for services it supports
- Service provider metadata
- Eve: does it make sense to aggregate all metadata for profiles?
- Scott: each profile calls out its own metadata; manageability issue
- Tony: dispatching method?
- Scott: HTTP Form POST and SOAP are separate profile
- Next steps
- Discussion of W-3 vs. W-4. Agreed to keep separate
- Rob: like to have one metadata work piece
- Krishna: send out spec and slides on e-mail list for further discussion
Jeff, Credential collector (W-17)
- next step is use cases
- defer until maybe tomorrow
Prateek, SSO Profile enhancements (W-5)
- SSO initiation profile
- user access a secured resource at SP
- user is redirected to an IdP; user selects IdP (W-7)
- IdP initiates one of the existing SAML SSO profiles
- context info needed
- id of the SP
- request ID
- URL of the original SP resource
- request time
- arbitrary relay data
- Liberty AuthnRequest
- SP issues AuthnRequest to IdP
- IdP authenticates principal if necessary
- federate principal IdP identity with SP identity
- issue temporary anon identifier
- use specific protocol profile to response to the request
- use specific authentication context
- Mike Beach: environments where SP doesn't know where IdP is
- Scott: relay through client; not a back channel message from SP to IdP
- Tony: is AuthnRequest readable by IdP? sensitive data like relay state
- Jason: protection mechanisms defined for relay states
- Bob: important to be extensible so apps can add their own controls; no
comprehensive list but can survey what's out there.
- Scott: nice to have some uniformity of extensions to AuthnRequest
- next step to call for comment on 2 proposals: SSO initiation and Liberty
AuthnRequest
Scott and John Linn, Identity federation (W-2)
- John: covered by Scott's Liberty presentation yesterday
- Scott: tied into SSO proposal
- John: part of whole architecture; can't proceed with blinders on and converge
- Scott: like to see request and response profiles kept distinct; John agreed.
- Scott: can address tech issues with Subject element
- Scott: highlight dependencies between work items
- Rob: first step defining set of requirements
- Scott: have use cases
- Tony: use cases beyond Liberty?
- Scott: like to see; encourage other people to think about them
- Rob: use case: request to return attributes for SSO.
Delegation and intermediaries (W-15 and W-16)
- Rob: relationship with WSS needs to clarified
- Eve: W-16 to be merged into W-15.
- Prateek: need use cases? Yes
- Bob: need Web service and 3-tier service use cases
Bob, Baseline attribute namespaces (W-21)
- X.500/LDAP attributes in SAML attribute assertions
- many attributes defined, why reinvent
- desiderata
- deterministic mapping
- works on all LDAP attributes
- human readable attribute names
- sensible use of SAML attribute schema
- avoid registry (avoid BECOMING the registry)
- Eve: can use DSML?
- X.500/LDAP attribute definition
- X.500 attribute definition
- position in type hierarchy (optional)
- attribute syntax
- equality, ordering, matching rules, cardinality, etc
- OID
- SAML AttributeDesignator
- AttributeNamespace, AttributeName
- XML data types
- no existing practice guidelines
- Eve: value designed in extensibility
- Rob: type part of the value, not part of the AttributeDesignator
- Eve: AttributeDesignator designed for query; has no value
- XACML approach: XACML 1.0 appendix B.5
- document URL naming
- human-readable
- not deterministic - many documents; probably need a registry
- URL doesn't resolve
- OID approach
- applies to all OIDs for all purposes
- deterministic for all X.500/LDAP attributes
- not human-readable; translation to local names required anyway?
- Phil: numbers are better; semantics easier for numbers than names
- Eve: not always...
- Prateek intervenes....
- Short-name approach
- all X.500/LDAP attributes have short-names
- Tony: why not use QNames?
- Scott: QNames break digital signatures
- Eve: need to follow up on syntactic representation and vocabulary
- Scott: number 1 federation work item is to develop vocabulary
- Irving: many deployments have LDAP directories
- Scott: enable interop between such deployments by using LDAP attributes
- Frederick: does Liberty define in attributes about principals?
- Scott: not in ID-FF.
- Eve: DSML example
- XML vocabulary and process to represent LDAP directory info, query and
update
- A lot of products already talk DSML
- Eve: UBL (Universal Business Language) codelists
- e.g. ISO currency and country codes
- spec for codelist producers to map codelists to XML schemas
- Bob: deliverable convention for referring to X.500 attributes
- John Hughes: have to register own OIDs?
- Bob: don't have to use this convention
- Scott: goal not to introduce complexity to attribute naming
- Bob: relation to metadata
- John Linn: SAML should be neutral; smallest amount necessary
- Bob: does that today
- Prateek: nice to have standard syntax
- Bob: separate issue with attribute name syntax related to type?
Scott, Discovery Protocol (W-7)
- destination site first flow: where to send user?
- Liberty introduction (really discovery) mechanism
- low impact way for user agent to give hint to SP on which IdP to use
- business agreements between sites; practical to use common domain cookie
- simple profiles to redirect browser to common domain to get cookie;
redirect user back with cookie value
- John Hughes: like a lot of cross-domain techniques
- Jahan: persistent cookies?
- Scott: don't have to be; persistent for past authentication; session for
recent authentication
- Jason: spec recommends one way; can't remember which
- Shibboleth approach (WAYF = where are you from?)
- no machinery for common domain
- intermediary in destination site first to interact with user agent to
determine IdP
- can be destination site or intermediate service
- can do with Liberty signed AuthnRequest
- use metadata to populate with IdPs
- Shibboleth has greater number of IdPs than common for Liberty; makes
common domain less practical; identify by university affiliation
- Jahan: cookie very browser specific; problem is not limited to browsers.
- Scott: LECPs supposed to have knowledge of IdPs, but may not in every case
- Irving: LECP can handle "get me better credentials" request; browser can't
Attribute retrieval enhancements (W-12)
- no champion
- Irving: overlap with attribute based SSO profile; "give me all attributes in
our agreed community of interest"; query by example? XML query? currently have
a big unspecified query extensibility and 3 very specific queries.
- Eve: maybe need work item to examine if we need more generic request-response
query vs. specific ones?
Bob, SASL Support (W-18)
- many IETF protocols use SASL (RFC 2222): IMAP, POP, SMTP, LDAP, ... (not HTTP)
- many security mechanisms for SASL: GSS/Kerberos, GSS/*, Digest, Plain, SRP...
- appealing to have SAML as a security mechanism
- might have authn assertion via browser profile
- better than username/password or worse...
- Profiles
- different subject confirmation methods have diff properties
- common use case browser profile; like SASL-PLAIN (password)
- different SASL mech for bearer vs artifact vs holder-of-key
- not particularly connected to SAML 2.0.
- Irving: confirmation method might be sticky point; multistep process in SASL
for confirmation; need to define how confirmation executed in SASL.
- completely independent of credentials collector
- Irving: could define authentication authority using SASL for authentication
that produces assertions; independent of this item.
Frederick, Enhanced Client Profiles (W-5a)
- LEC knows how to find an IdP for principal + SP; can deal with AuthnRequest
from SP.
- no redirects, no cookies; good for proxy clients
- reduces bandwidth requirements
- Flow
- LEC gets AuthnRequest from SP (HTTP GET with LEC header)
- LEC sends AuthnRequest in SOAP to IdP
- IdP sends AuthnResponse in SOAP to LEC
- LEC sends AuthnResponse to SP
- SP sends 200 OK, ...
- AuthnRequest extends SAML abstract request.
- Scott: LEC doesn't have to look into AuthnRequest; just forward to IdP
- AuthnContextComparison specifies how to match actual authn to requested
AuthnContext classes.
- Jason and Jeff: LEC could be a browser with a Liberty-enabled plug-in.
- Prateek: general web service case not covered in Liberty
- Jason: use of SOAP not intended to be necessarily lightweight; just reduce
redirects...
- Scott: leaves SP relatively unmodified; most mechanics for SSO remain
unchanged
- Irving: relevance to pure web service environment; fault to force
authentication belongs in SAML?, WSS-SAML profile?
- Authentication Context
- Authentication identification, technical protection, operational protection,
etc.
- Grouped into quality of authentication classes to reduce complexity
- Bunch of authentication classes defined by Liberty
- AuthnRequest work item needs to include authentication context.
- Scott: SSO in Liberty doesn't depend on authentication context.
- Bob: critical/non-critical issue; what if I don't recognize a context?
Eve, Docset proposal
- Non-normative documents
- Technical Overview (new) [John Hughes]
- Audience: new implementor
- Move domain model here
- Add complete examples
- Security/Privacy Considerations (existing) [Frederick]
- Examine similar info in SAML Bindings/Profiles
- Examine similar Liberty data for applicability
- Implementation Guidelines (new) [Steve]
- Compare against Liberty spec
- Auxiliary documents
- Scope/work items (existing) [Eve]
- Document accepted requirements and use cases here
- Issues (new) [Eve]
- Errata (new) [Jahan]
- Normative documents
- Assertions/Protocol (existing) [Eve]
- Minus Introduction
- Compare against Liberty Protocol and Schemas spec
- Schemas (existing)
- Bindings/Profile (existing) [Frederick]
- Greatly expanded
- Compare against Liberty Protocol and Schemas spec
- Conformance (existing) [Prateek]
- Greatly expanded
- Metadata (new) [Jahan]
- Authentication Context? (new)
- Check with Paul Madsen
- Compare against Liberty AuthN Context spec
- Glossary (existing) [Rob]
- Outreach documents
- Website (existing) [Rob]
- FAQ (existing) [Eve]
- Executive overview (new) [John Hughes]
- Audience: manager-level
- Possibly based on existing white papers
- Covers ROI, etc.
- White papers (new)
- Eve: OASIS doesn't recognize normative vs. non-normative
- Jeff: Liberty architecture overview too technical for non-technical readers.
- Jeff: SAML Glossary is normative
- Eve: commission creation of a test suite?
- Prateek: spending a lot of time advising on integrating SAML products;
encourage conformance doc and will work with 3rd party on test suite
- Scott: how formal, branding?
- Eve: probably not because of legal implications
- Eve: lack of reference implementation or test suite makes SAML look less
professional, even though we have good interoperability
- Eve: FAQ and white papers ideally done by a marketing type.
Timeline
- Eve: original v2.0 goal OASIS spec 2Q04, committee spec 1Q04.
- Jahan: number of work items dependent on Liberty, moving target?
- Scott: non-editorial freeze for Liberty v1.2 end of this week
- Rob: target enter last call end of 1Q04: Friday, April 2, 2003.
(internal review before committee draft)
- Eve: close work item list by Tuesday Sept 30, 2003
- Doesn't mean issue list is closed
- All issues without owners will be dropped at that time
- Phil: have some items rearranging stuff for WS-Security, etc. Separate
assertion framework from assertion statements.
- Prateek: By Tuesday Oct. 14, 2003 all work item owners produce use case
proposals or other next step deliverables.
- Simon: one mailing list for all work items? yes
- Eve: dovetail next F2F with XACML meeting in San Jose, Oct. 22-24? maybe Sun at
Santa Clara? goal of F2F to entertain solution proposals.
--- End Message ---
--- Begin Message ---
From: "Eve L. Maler" <>
To: "Philpott, Robert" <>
Date: Wed, 10 Sep 2003 12:07:50 -0400
Title: Minutes from Wed morning
Minutes from 10 September 2003 SAML TC meeting
Submitted by Eve Maler
[We should probably extract all the "waiting for..." notes in the work
item document and turn them into official action items.]
The TC briefly reviewed the work items discussed yesterday for the
people who missed the discussions due to the XACML breakout meeting.
XACML Presentation by Anne Anderson
(see the Proposed SAML 2.0 Changes from XACML TC and OGSA, version
1.7, from Anne)
The Authorization Decision work in SAML V1.0 was acknowleged to be a
first cut, with experts in the area continuing to work on it in XACML.
Later, it was discovered that the people working on an architecture
for grid services had additional requirements in the same area.
The requirements presented today came out of the last two months'
joint talks. They are abstract and don't specify a syntax.
XACML had originally intended to use the SAML request/response
protocol and develop its own assertions, but it ended up with
different protocol requirements and so went on its own path. The
group is now proposing that these changes be reintegrated into SAML.
It's important that both SAML and XACML be able to be used apart;
these requirements focus on their use together. XACML has a generic
input context and output context.
The XACML request context is a collection of attributes about the
subjects, resources, and actions involved, for example various
identities of the users and machines involved. It assumes that all
these attributes have been authenticated; it's out of scope.
The proposal assumes a SAML AuthZ decision query/statement and an
XACML request/response (input/output) context.
Requirement #1: A way to pass an XACML Request in the SAML Query, and
an XACML REsponse in the SAML Decision.
The XACML Subject element is a collection of attributes about zero or
more subjects. Thus, there is a mismatch between XACML and SAML
subjects. A request for an authZ decision, given this, is not a
request about a SAML subject.
The XACML response context includes the decision.
Scott: Is there something to be gained by expanding SAML's notion of a
subject towards the XACML direction? Ideally we don't want to create
slightly different vocabularies in the same space.
Requirement #2: A way to return an XACML Request as part of the SAML
Decision, and a flag in the SAML Query to indicate whether an XACML
Request is to be returned as part of the SAML Decision.
Other requirements:
- Associated a DataType with an Issuer name, such that the name can be
determined to be a string, an X.500 Distinguished Name, etc..
- Better correspondence between the SAML Attribute format and XACML
Request Context Attribute format.
- A new SAML Policy Statement syntax.
- A new SAML Policy Query syntax.
On these last two, it's not clear whether SAML should be picking up
this work; they're bringing this up for discussion. SAML seems like
the appropriate transport for this policy information. One
"unwritten" requirement is that SAML and XACML should be able to be
used separately (as well as together), so any mutual dependencies
would need to take this into account.
Some specific suggestions are being made as to changes to the SAML
AuthorizationDecisionQuery and AuthorizationDecisionStatement
structures. In it, "XCAssertionType" is a temporary name standing for
"XACML-compatible assertion type". (Strictly speaking, an
"XCAssertion" doesn't need to be specially allowed in assertions and
so on, since it's based on SAML's AssertionType, which is already
allowed.)
The naming in the XACML proposal of "xacml-context:Request" and
"xacml-context:Response" may be confusing because these go inside a
SAML statement, which goes inside a SAML response. It may be easier
to think of these as "Input" and "Output" context information, so
there isn't an indirectly nested response-thing. Eve: The SAML
Response element allows for a series of Assertions to accompany a
response as context, which may be another way to pass this information
(though perhaps the SAML structure is currently too constrained).
XACML has four possible return values, not just three as in SAML:
Permit, Deny, Not Applicable, and Indeterminate.
This proposal is intended to let the PDP and PEP fully communicate.
Prateek: The requirements are very helpful, but the design proposal is
confusing. Scott: We need to be clear about the semantics of the
communication we want. Rob: And we have to watch out for mutual
dependencies. Hal: This is the problem with just having SAML carry
the XACML input and output contexts, since SAML will then depend on
XACML and changes will be difficult.
Continued discussion: How many people are currently using AuthZRequest
and AuthZResponse protocols from SAML? A few people are using the
current protocol (Entrust, Sun, Oblix) but no seems deeply attached to
it.
Scott: Would be interested in pointers on the mailing list about doing
attributes in XACML's way vs. SAML's. Irving: Why did XACML use URI-
based attribute naming? Hal: XACML can also use an XPath expression
into a context. Scott: SAML has a two-part name, and XACML has a one-
part name that's a URI. We're now considering how to accommodate
things like X.500 attributes in a standard way; XACML has an appendix
that discusses this.
Hal: SAML and XACML both have a Conditions element, but they mean
different things. XACML has a notion of "obligation", which is an
additional instruction to make something happen in addition to
"permit" or "deny". The problem XACML has with SAML's version of
Conditions is that it's at the Assertion level, not the Statement
level. Irving: It's possible to put things in a SAML Condition that
amount to an obligation.
Prateek: Should we work on this proposal more here today? Do we need
a joint task force? Hal: We should add a couple of work items for the
specific points: policy wrapper, attribute reconciliation, and
authorization decision statement reconciliation (which includes the
conditions/obligations question).
Irving: If you look at what Liberty and Shibboleth have done, they
have taken useful objects from SAML but used a different way of
shipping them around. XACML might be interested in using SAML-based
objects and transporting them.
We broke out the existing W-28 work item into four specific ones and
assigned owners.
W-10 Back Office Profiles
Irving: The use case for this sort of thing is a lot like the multi-
participant flows we discussed earlier. It involves attaching SAML to
business transactions. Prateek: This is sort of like the WSS token
profile. Eve: But the assertions would apply to the behavior in
processing the payload. Irving: The business data proabably wants to
incorporate the SAML information directly into its semantics for
issuer names, approver names, etc. that are used in workflow. Hal:
But it's attractive to factor out this information from the
application data, based on what we've learned in the industry in
recent years.
Scott: When people talk about security tokens, they talk about
"message security" but also "message authentication". As noted
earlier, maybe we need profiles or at least guidelines for the
semantics of attaching particular kinds of assertions. If a workflow
engine depends on SAML tokens as input to the next step of the
workflow, it's not clear whether this wants to be at the message layer
or the application layer.
Irving: If you attach an assertion with spending authorization in a
WSS header, you constrain everybody downstream to keeping that wrapper
around. Prateek: This "hegemonic" approach. RLBob: There would
have to be SOAP databases. Frederick: Or you can strip off the
relevant parts. Scott: But stripping off parts gets difficult with
signatures. Hal: The auditor has to capture everything.
Hal: By extension with X.509, you're providing extension operands for
encryption etc. The only type of SAML statement with an obvious
semantic is an attribute statement; it's not clear what the other two
mean.
Prateek: Hal's WSS interop profiles are the closest we have to
guidance. Hal: Plans to drive these sorts of interop questions in the
WS-I Basic Security Profile group.
Hal: Added usage attributes to STRs in order to help interoperability.
Scott: We need to define specific usage attribute values and attach
semantics to them.
Scott: The WSS TC currently holds the responsibility of fixing these
interop concerns, but we are experiencing these concerns today (though
they're pretty much orthogonal to our SAML V2.0 work).
W-19 HTTP Binding
Steve: We shouldn't have an HTTP binding since it doesn't add
functionality and creates disjoints between products that want to
connect and be interoperable.
Scott: Would be happy to have someone say "let's not do this." It
would be useful to dereference a URI to obtain an assertion. This is
related to "an HTTP binding", but doesn't have to be closely related.
Jeff: Could imagine a saml: URI scheme that, like the ldap: scheme,
could be dereferenced to get an assertion. This lets us define the
syntax how we like.
Scott: IETF has strong resistance to new schemes. Eve: Deploying
support for a new scheme is iffy. Scott: Defining an HTTP binding
would have the advantage of being unambiguous -- GET blah <assertion-
id>.
Jeff: It's useful to have a way to do a GET to retrieve a SAML object.
Frederick: This is a RESTful method.
We renamed this work item "HTTP-Based Assertion Referencing".
Scott: Would like to connect this up with STRs.
W-9 XML Encryption
Hal: The requirement is to be able to encrypt all or parts of
assertions, to combine this arbitrarily with signing in either order.
Scott: You also want, when you encrypt something, to handle it as the
logical thing that it represents in SAML. An encrypted SAML subject
(or whatever) should be able to be treated *as* a subject. This is
the hard part.
Irving: When you encrypt content, it would be nice if you could still
access the encrypted version of some subpart of that content. Hal:
This amounts to only encrypting the content, not the markup.
Scott: The process of encrypting results in something that isn't a
legal SAML construct. E.g., NameIdentifier is a simple type and you
can't derive a complex type from a simple type. There are schema-
change implications to enabling more of what we want to do.
Eve: The XML Encryption people explicitly punted on the XML validity
of encrypted stuff. This could be solved through alternative
structures baked into the schema, through an entirely alternative
schema, or through workflow that has late encryption and early
decryption.
Frederick: If you don't care about validation, it may be acceptable to
tolerate an encrypted version.
Hal: There are special considerations around encrypting passwords and
subject confirmations. You could have both guessing and replay
attacks.
John Linn: For NameIdentifiers, is there any advantage to
transparently plugging in one of two alternative elements vs. an
element that branches out to the choice? Scott: They're roughly
equivalent.
Eve: So the use case is a processor that is taking existing encrypted
content and constructing new content out of it. Scott: Yes; this
needs to be addressed by anybody using XML Encryption, since XML
Encryption itself didn't choose to address it.
Scott will become the long(er)-term owner of this work item, with an
emphasis on the XML aspects.
W-17 Credentials Collector and Assertions
Jeff: In Liberty, they've defined a SOAP-based protocol for doing SASL
requests and responses (as SOAP reuqest and responses), where the
response has an assertion with an authentication statement. The
Liberty draft, called SOAP Authentication, is publicly available now.
This achieves "peer authentication" (whereas WSS handles just "data
origin authentication").
The SOAP node receiving the request would be an IdP (identity
provider). The SOAP node sending the request would be a user agent;
it could be Liberty-enabled, but doesn't have to be.
The stack might be SOAP over HTTP over TCP over IP, where HTTP might
be over TLS or it might not. SASL has a notion of signaling "look
down your stack to see what's going on underneath you, and make use of
it for deriving your authentication identity".
We need to agree on use cases that define "pass-through
authentication"; Jeff and Tim have been talking about this.
Scott: If we defined a SAML mechanism in SASL, what relationship would
it have to what was just proposed? You you build a protocol for peer
authentication building off of data origin authentication.
Goal statement
Eve moved that we accept the following text:
========
The goals of the SAML 2.0 effort include:
o Addressing issues and enhancement requests that have arisen from
experience with real-world SAML implementations and with standards
architectures that use SAML, such as the OASIS WSS and XACML work.
o Adding support for features that were deferred from previous
versions of SAML for schedule reasons, such as session support, the
exchange of metadata to ensure more interoperable interactions, and
collection of credentials.
o Converging on a unified technology approach for identity federation
by integrating the ID-FF specifications contributed to the TC by the
Liberty Alliance.
========
Adopted by unanimous consent.
Telecon schedule
We agreed to continue to meet biweekly (September 16, 30, and so on)
until the next F2F meeting, and then consider going to a weekly
schedule after that if it seems warranted.
The editors are going to have a short meeting on the off-week of
September 23; Eve will send details on this shortly.
Thanks to host
The group unanimously approved Eve's motion to thank Rob Philpott and
RSA for the excellent venue for this meeting.
Adjournment
The group unanimously approved RLBob's motion to adjourn.
--
Eve Maler +1 781 442 3190
Sun Microsystems cell +1 781 354 9441
Web Products, Technologies, and Standards eve.maler @ sun.com
**********************************************************************
SunNetwork 2003 Conference and Pavilion http://www.sun.com/sunnetwork
September 16-18, 2003 Moscone Center, San Francisco
An unparalleled event in network computing! Make the net work for you!
--- End Message ---
← Prev in month
← Prev in thread