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


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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

Subject: 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



  1. 9/8 - Approved minutes of 2-Sept-03 SSTC con-call minutes as amended by Eve's email
  2. 9/10 - The group unanimously approved Eve's motion to thank Rob Philpott and RSA for the excellent venue for this meeting.


Action Items:

  1. All - Anyone interested in participating in an interop/demo at XML2003, contact Eve.
  2. Rob - Get all presentations posted to the list (see below)
  3. 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.


  1. Boeing - Mike Beach: posted to list.
    1. http://lists.oasis-open.org/archives/security-services/200309/msg00056.html
  1. Fidelity - Patrick Harding: awaiting okay from Patrick before posting
  2. Netegrity - Leo Laferriere: awaiting slides.
  3. WS-Security - Ron Monzillo: awaiting slides.
  4. Liberty ID-FF - Scott Cantor, Jeff Hodges: awaiting slides
    1. Jeff's flow diagram: http://lists.oasis-open.org/archives/security-services/200309/msg00039.html
  1. Kerberos use cases - John Hughes: posted to list.
    1. http://lists.oasis-open.org/archives/security-services/200309/msg00035.html
  1. Sessions - John Kemp: posted to list.
    1. http://lists.oasis-open.org/archives/security-services/200309/msg00037.html
  1. Metadata - Jahan Moreh: posted to list.
    1. http://www.oasis-open.org/apps/org/workgroup/security/download.php/3448/F2F_MetaData_090803.pdf 
  1. Authentication Context - Frederick Hirsch: posted to list.
    1. http://lists.oasis-open.org/archives/security-services/200309/msg00047.html
  1. LECP - Frederick Hirsch: posted to list.
    1. http://lists.oasis-open.org/archives/security-services/200309/msg00048.html
  1. 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 ---
Title: SAML F2F Minutes 9/8/03 AM meeting


        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
        Mike's presentation - Done
        Patrick's - TBD
        Leo - TBD

The group broke for lunch at around 12:15.


--- End Message ---
--- Begin Message ---
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 ...

 - 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
      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 ...
  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
    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)
  entity operational/policy
    service endpoints
    supported versions
  "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
  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 ...

  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 ---


--- Begin Message ---
Title: Minutes for the SAML F2F Sep 9 2003 Afternoon

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
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
  - 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
- Scott: leaves SP relatively unmodified; most mechanics for SSO remain
- 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,
  - 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. 
- 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 ---
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

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

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

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-

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

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

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

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.


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 ---

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