[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Absolutely final and complete minutes from SAML F2F, February 2-5, 2004
Apologies for repeatedly missing sections provided by our six minute takers. Thanks to Hal and Eve, I believe this is the complete set of minutes. - prateek
Minutes from the SAML 2.0 F2F, Feb 3 - 5, 2004
----------------------------------------------
1. Attendance
http://lists.oasis-open.org/archives/security-services/200402/msg00058.html
We have quorum for the meeting (25 out of 35 voting members present)
2. Approval of Minutes from last official conference call
http://lists.oasis-open.org/archives/security-services/200401/msg00069.html
3. Tuesday proceedings
Morning Session
---------------
W2 - Identity federation
Rebekah Lepro not here?
Some confusion
Stick to original plan.
Reviewing interim draft 03b
Section 2.3 first modified section.
Eve/Scott - NameID section moved up in document. Now a BaseNameID that
underlies both string-based and encrypted element NameIDs. New element.
Prateek - replaces 1.1 NameID Is it backwards-compatible? "morally" compatible -
Eve John Linn - NotBefore attrib - is it bound to the time of encryption?
Post-dated identifiers?
Scott - no use-case in mind, but use of temp NameID. If proposals for
SSO were adopted, use for timestamps would only be for encrypted
NameIDs, and NotBefore would be the time of encryption.
Hal - text implies tie between auth and encryption. No sense in a timestamp.
Scott - can decrypt Kerb tickets at any time. Hal - time encrypted has no relevance, only signature is relevant Scott - this is normally symmetric encryption Hal - having this info is generally useful. Scott - timestamp is there for privacy protection - ie. NameID is rolled
over frequently. Assertion will not be signed.
Hal - you can re-sign.
Frederick - why is this the time the encryption was performed?
Scott - purpose is that relying party can ensure that NameId was
encrypted by right guy at some time party finds reasonable.
Scott - two basic use-cases. One goes away.
Scott - can we remove these attributes, based on the assertion validity
period changes?
If you can change the NotBefore date, then does it have value to relying
party?
Scott - needs some integrity protection
ISSUE: Consider removing NotBefore/NotOnorAfter based on sessions
discussion. Sync up validity period (Scott)
ACTION: Scott to think about this more
Hal: Need to re-sign anyway
Scott - NameQualifier identifies issuer.
Hal - this becomes a mini-assertion.
Eve - Issuer is now an element based on NameID, not an attribute
Hal: What is logic for not making this more generalized?
Scott - sensed that it would be harder to say it was string type
Hal - uc is issue attrib assertion about an issuer Why not encrypt Issuer's ID?
Hal - sharply limit the things you can encrypt
Scott - Issuer will be a "SAML authority". Default Format.
Eve - consider default Format value in schema. Could say that default is
profile-specific?
Scott - uncomfortable relying on profiles
Eve - withdraws suggestion
ISSUE: Default attribute?
Scott - issuer not necessarily the same entity as signer of assertion
Greg - relationship between Issuer and metadata? Hal - signer speaks for the Issuer
James Vanderbeek (Vodafone), Paul Madsen (Entrust) joined on call
Jeff - not carving out SAML concall
Frank Siebenlist, Von Welch joined on call
Scott - want to be able to say in profile that Issuer must be signer
Moves us away from cert modesl that exist
Hal - Subject and SubjectConfirm may have nothing to do with NameID of
Issuer
Eve - should we change something?
What is your model for validating the Issuer?
Hal - your policy can be whatever you want
Scott - trust models about Issuer being assertion signer (or not)?
Eve - does trust-models doc speak to this?
John L - no
Bhavna, Sun, Timo, Nokia joined call
Eve - what would we say in text here?
General agreement that text is good
Scott - no problem to either define or leave undefined in specific
cases. This is not inconsistent
Scott - sentence is innocuous, but has implications
Eve - line 1073, refactoring of request/response
Scott - added Issuer to request and response, to aid quick evaluation of
request
No authority that writes assertions in a certain way - leave it up to them
Scott - explains RelayState presence in req/resp
Eve - difference in queries
Scott - all stuff that used to be in individual requests (Assertion,
Artifact etc) is now in a base type. Now WSDL can reflect individual
support of protocols (I support AttributeQueries but not other types)
Scott - response is how you send back StatusResponse with 0 or more
assertions.
Tim Moses, Entrust, Emily Xu, Sun on call.
Eve - NameIdentifier element ref'd is no longer general enough in 3.3.4.1
Federated RNI - new protocol
Scott - IOP Issues around it, with Format, NameQ. Explains RNI protocol
messages.
Prateek - only IdP?
Scott - no, SPs too
Prateek - privacy is key here - this is why RNI exists.
ISSUE: any place we bring in Liberty work, we need to check assumptions,
because Liberty assumes certain things about protocols. Specifically,
check usage of non-federated id in RNI. (Scott)
Assertion vs. Artifact - Eve suggests ArtifactRequest and
AssertionIDRequest both return an assertion, so names should reflect that.
Scott suggests that they are different.
Eve ArtifactRequest is RequestByArtifact
Hal - should be 1-1 assertion to ID, whereas artifacts can be one to
multiple assertions
Eve - actual wording looks good.
Eve - blocked substitution in schema
Eve made distinction between normative and non-normative references Hal - is Unicode normative?
Rob - OASIS is submitting SAML 1.1, XACML 1.0 to ITU-T
Hal - they will roll forward with new standards, things will be easier
because of this submission.
Eve - how do we see this spec. suite? We have several specs. Entry point
into suite is currently SAML conformance document.
Jeff - write intro document that does this (like LDAP).
Hal - SSL issue
Scott - inserted text about attribute values - multiple attribute values
(lines 828-830)
Eve - null AttributeValue can be ommitted. AttributeDesignator holds the
name. Eve proposes element MUST be ommitted.
Scott - ambiguity for null string.
Greg - finesse by saying 'has no value'
Agreed - If the attribute exists but has no value, then the
AttributeValue MUST be omitted.
Scott - more controversial RECOMMEND each value appears in its
own AttributeValue.
Irving - why not MUST?
Scott - trying to be loose with this, as there are use-cases
Eve - great to have structure there if you want to use it
RLBob - say more about this
Eve - moves to accept Core 04 as a working draft of the group,
Jeff seconds Any discussion? No,
VOTE
Any objections? None, accepted.
W2, 28D done
Adjourned till 2:30
OASIS Security Services TC
Feb. 3, 2004 Afternoon
-------------------------
On the phone: Emily Xu, Tony Nadalin
W-1: Session Support, John Kemp
- Reference:: http://lists.oasis-open.org/archives/security-services/200402/msg00013.html
- Proposal 1: Use assertion ID and validity period to represent the session and validity period.
- Hal: Assertion ID is not really session ID, but used to identity session by the session authority.
- No separate piece of XML to represent session in SAML protocol.
- Authentication authority and session authority are the same.
- Hal: Neither proposal extends life of session.
- Scott: SP can treat new assertion as a continuation of a session if it wants. One purpose for relay state: session token.
- Mike B: Use case for session with multiple authentication assertions? Hal: Sign on with password then later with certificate.
- Ron: Does session have to be bound to an authentication event?
- Hal: Objective is dynamic session termination.
- Scott: Not a general purpose solution for accounting, message protection (e.g. Kerberos).
- Validity period discussion
- Hal: In artifact & post profile, assertion validity max time to initiate SSO (short lived), not length of session.
- Prateek: Meant to be an introduction protocol.
- Rob: Use local session policies after using assertion to initiate session.
- Steve: Have to remember something about the session, e.g. assertion ID, and have some expiration on the stored data.
- Scott: Always had IssueInstance for freshness control.
- Mike B: Concern about SPs ignoring assertion/session expiration.
- Prateek: IdP control over lifetime of assertion important.
- Mike B: SPs have specific timeouts; user still logged in at IdP; need to force re-authentication. Hal: can be handled by proposals.
- Prateek: Why not propagate session lifetime as well as assertion validity?
Hint vs. enforce. Conformance behavior for SP.
- Logout Proposal: Send logout message if principal logs out, session authority notifies participants. (ID-FF 1.2)
- Ron: If message doesn't go through, can't log out. Best effort.
- Scott: IdP batches all assertions it considers a session.
- Scott: Case where rule can't exist: Web browser and phone log in; different sessions.
- Hal: Participants should agree one way or another but be consistent.
- Hal: SP can ask session to logout, SA can tell SPs when session is logged out.
- Discussion on whether a SP can say "no" to a logout.
- Hal: Session only for those who explicitly asked for it, so should only participate if can honor logout.
- Rob: Hand off session to a legacy system with no way to end legacy session.
- Discussion of polling for validity vs. waiting for logout messages.
- Hal: Either IdPs have to keep track of which SPs have been given assertions, or SPs need to handle logouts for sessions they don't know about.
- John: Could do what Liberty does with Session ID in authentication assertion.
- Ron: What is SP state for session? Scott. etc: Assertion ID, maybe original assertion,
maybe related local state. Hal: need to track touch time if care about idle time.
- Motion by John: Incorporate ID-FF v1.2 logout protocol, with extension into SAML v2.0.
- Seconded by Hal.
- Discussion
- Hal: Concern with using same logout message with different semantics.
- Mike B: one way is logout notification, other way is logout request.
- No objections.Motion carries.
- Hypothetical motion: Use assertion ID as the session identifier.
- Mike B: Why not use Liberty concept of session ID in the assertion?
- John: More simple to use existing assertion ID than introduce additional elements.
- Scott: Some problems with ID-FF sessions; required some cleanup; clean now.
- Mike B: Would like convergence between Liberty and SAML.
- John: Liberty providers would implement SAML 2.0.
- Compromise proposal: use assertion ID and include session ID in authentication statement?
- Ron: Prefer in Subject statement for other types of statements; John: was there originally.
- Timeout Proposal (Hal): One max idle timeout for all SPs; individual shorter SP timeouts.
- Central session authority (SA) keeps track of session activity. All SPs report touch time to SA (one way). SA keeps latest touch time.
- If max idle timeout occurs, session logged out for all SPs.
- If individual SP timeout occurs, session logged out for that SP.
- R.L. "Bob": SA should notify SP if the session doesn't exist anymore. Ron: Touch time notification could need a response sometimes.
- SA periodically scans touch times to find those older than max global timeout or individual SP timeout, then sends logout requests to SPs.
- Steve: Desire more on demand update of touch time. User sends a browser request that exceeds local SP idle timeout; ask SA the last touch time, SA might poll other SPs.
- Hal: concern about scaling
- Irving & Scott: requirement for front channel binding.
- Greg: Hybrid approach: SPs report touch time only when they see a user.
- Steve: Issue with resource access through components with no SAML knowledge.
- No agreement on next step.
W-5: SSO Profile Enhancements, Prateek Mishra
- Proposal 1: Replace SAML 1.1 profiles with ID-FF AuthnRequest: SP->IdP; AuthnResponse: IdP->SP
- Proposal 2: Accept materials in section 3.2 for abstract AuthnRequest and AuthnResponse protocol.
- Map AuthnRequest/Response to existing web SSO profiles.
- John H: Not clear can use AuthnRequest for artifact. Scott: artifact represents a response.
- Scott: Can't divorce AuthnResponse from the Liberty assertion.
- Scott: Review of AuthnRequest schema
- Extension: allows derivation of new types from AuthnRequest.
- ProviderID: superfluous now that Issuer is in the SAML 2.0 request; will be dropped.
- AffliationID: request authentication as part of an affiliation.
- R. L. "Bob": collection of SPs - implicit SAML support requirement.
- NameIDPolicy: enumerated type -- desired name ID and federation operations,
e.g. use existing federated ID, but don't establish a new federation; Needs to be generalized for SAML.
- Jeff: Need to be careful to have true convergence with Liberty, backwards compatibility with existing Liberty values.
- Discussion about increasing protocol size. Agreement for now to keep one document for assertion and protocols.
- ForceAuthn: IdP should try to interact with principal to re-authentication
- IsPassive: don't interact with principal. Discussion of relation with ForceAuthn.
- ProtocolProfile: which profile to use for the request; decomposes request and response profiles, but different profiles not used by anyone?
- AssertionConsumerServiceID: used to identity the AssertionConsumerService URL; SP can have multiple such URLs. Example: regional consumers.
- RequestAuthnContext: authentication requirements; statements of policies and procedures
- RelayState: now in base request type.
- Scoping: proxy use case
- Consent: have obtained user consent for operation.
- Liberty says request should be signed but does not require it.
- Review of AuthnResponse schema
- Extension
- ProviderID -> Issuer
- RelayState
- Carries assertion as per base type.
- Liberty requires assertions to be signed for use as security tokens. Not practical
to sign both assertion and response.
- Liberty assertion contains InResponseTo vs. SAML response.
- Liberty assertion uses Audience (name of consuming SP) vs. SAML response Recipient (SP location URL).
- Prateek moved to accept Proposal 1 and 2. Eve seconded.
- Discussion
- Tony: why totally get rid of SAML 1.1 profiles?
- Prateek: Adopt abstract AuthnRequest-Response and then revisit concrete implementations.
- Tony: concern about existing implementations. Irving: how different from existing implementations?
- Scott: resulting architecture not too different.
- Charles: Example of post profile, what would change would be response in the post.
- Charles: One motivation is solution of "destination-first" problem? Prateek: yes.
- Motion is to accept this as a starting point for subsequent work.
- Motion carries by unanimous consent.
W-5a: Enhanced Client Profiles, Frederick Hirsch
- Goal: Bring solutions enabled by SAML to a wide variety of devices
- Enhanced client or proxy (ECP): IdP- --- ECP ---- SP
- ECP profile:
- ECP request to SP
- SP requests authn in response
- ECP gets assertion from IdP
- ECP returns assertion to SP
- Profiles:
- Legacy-SP (HTTP only for SP) = LECP
- Reverse HTTP SOAP binding PAOS + LECP = PECP
- PAOS: reverse-HTTP binding for SOAP, solicit-response message exchange pattern.
- PAOS + LECP: eliminates custom AuthnRequest/Response envelopes, uses custom SOAP headers
- Issue: use of PAOS + LECP as a general mechanism for SOAP clients.
- Question on how agnostic proposal is to SOAP version. Scott: do we need normative spec language for SOAP 1.2?
- Jeff:: what is depth of penetration of SOAP 1.2 in the marketplace?
- Proposals:
- Adopt LECP solution (draft 5).
- Adopt PAOS + LECP solution (draft 1).
- Integrate into SAML 2.0 bindings and profiles specs.
- Frederick moved to accept proposals; John K. seconded.
- Discussion of relation between these proposals and other proposals to be discussed later in this F2F.
- Motion tabled. Discussion to resume tomorrow.
4. Wednesday, february 4
Minutes for Wednesday morning session of SSTC meeting, collected by John Linn
Rob Philpott called the session to order, and Prateek Mishra collected attendance.
Discussion of W-5b: SOAP Client Profile (Mike McIntosh):
The document covers 3 scenarios:
· SOAP requestor of SAML assertion to be sent to service
provider;
· proxy-based SOAP request for SAML assertion, where proxy
forwards assertion;
· service requests SAML assertion for SOAP client
For each case, the WSS SAML token profile is used to protect the SAML assertion.
The client authenticates to the service provider using some mechanism other than SAML.
Tony observed that this proposal represented one of many possible integration approaches.
Scott observed that the use of the SAML token profile to protect the returned assertion appeared unusual.
Irving Reid observed that credentials in WSS messages seem to serve two distinct
purposes: message protection and/or proof of identity, and that this overlap can be confusing.
Towards the end of Sec. 3, Ron Monzillo observed that step 2 might represent an appropriate use of the SAML Token profile,
rather than step 5 as described. Per steps 4 and 5, Irving commented that it seemed strange to use SOAP header elements;
Tony Nadalin asserted that it appeared natural for
use within a WSS environment. Generally, there was controversy about the
relative merits of applying SOAP header elements vs. layers enclosed within SOAP messages.
Irving presented a diagram for a candidate flow, in which a SOAP client requests an operation from an SP,
carrying an abstract ticket to authenticate itself. The SP, in turn, invokes an IDP to obtain an assertion.
Irving recommended that these elements be placed in the SOAP body rather than the header. Mike compared this to his proposal,
where the client authenticates using WSS. Irving believed that, in certain deployment models, WSS wrappers might be applied and
removed at lower implementation layers, making it difficult to also use the WSS layer to provide the functions being considered.
Irving observed that Mike's model appears to be oriented to a relatively low-function SP, performing only limited processing and
acting as a pass-through for unmodified data elements. Tony sees some similarity between aspects of Mike's proposal and Scott's proxy materials.
Bob Morgan was unclear as to what models this proposal would enable which are not already possible within SAML.
Rob noted that this adds specification for the use of authentication based on WSS. Scott was not
sure as to whether the SSTC should profile WSS usage. Prateek asked about
next steps, based on these proposed use cases and solution elements. Irving believed that the translation of one WSS message to
another is properly a WSS profiling activity, rather than a SAML activity; Tony believed that profiling WSS, carrying SAML assertions,
was no less appropriate as a SAML activity than profiling HTTP-based SSO protocols. Eve asked, what would this solution provide that
composition of existing elements couldn't offer? One possible value is that it provides a push model.
Prateek asks whether the TC will accept the use case; Eve believes that the TC does not yet fully understand the proposal and its benefits,
and asks for timely clarification. Given the SAML 2.0 schedule, she further observes that such work may need to be considered within a
subsequent phase. Scott believes that existing elements (possibly with certain extensions, as to request a token for another identity)
can satisfy the first two proposed functional scenarios, assuming that requests are made within the SAML protocol.
Eve Maler suggests (and Prateek concurs) that the proposal's proponents should provide additional use case motivation and
clarification for follow-up discussion (possibly tomorrow), in the context of SAML and the WSS SAML token profile.
Scott and Irving also plan to contribute to this analysis, considering both aspects of SAML 1.1 and of current SAML 2.0 work in progress.
Discussion of W-25: Kerberos Support (John Hughes, Tim Alsop):
Two documents have been offered, per restructuring discussed on TC con call:
· Generalized AuthnRequest Protocols and
· Kerberos SAML Profiles.
The Kerberos-specific profile needs an updated solution proposal, which is hopefully to be provided this week.
A user's workstation runs code causing the described SAML service (which corresponds to the SAML authority as described in other terminology)
to return an AuthnResponse, using Kerberos to protect the interaction with that service. While Kerberos can be used for a number of functions,
the proposal emphasizes its use to securely pass a user identity to the SAML responder via the SAML service. Among several other uses,
Kerberos can also be considered as an alternative to SSL to provide a secure channel. Noted: Kerberos TLS ciphersuite definition exists,
but has not been widely implemented. John Linn asked whether it was within SSTC scope to define approaches to provide secure channels, vs.
recommending that secure channels be provided at layers below SAML?
The primary use case concerns use of a Kerberos ticket as input to obtain a SAML assertion, reflecting the identity obtained from the ticket.
The proposed approach establishes a GSS-API security context to the SAML service, carrying GSS tokens within a variety of protocols;
identified customer requirements have not been SOAP-oriented. Jeff Hodges suggested that this use case be treated generically, also
accommodating other mechanisms than Kerberos.
Schema elements were proposed to represent DCE/Microsoft privilege attribute certificate (PAC) contents within attribute statements.
Name identifier forms were also proposed to represent Kerberos principal names; following recent reconsideration, proponents now suggest
that the Kerberos realm be included as a qualifier to the individual principal name. Hal Lockhart asked whether UUIDs should be represented.
Identified outstanding issues include mapping to Microsoft PAC data, how and why to bind Kerberos credentials to SAML assertions
(e.g., including Kerberos keys as confirmation methods), additional detail on Kerberos/GSS-API bindings, and appropriate use of existing
Liberty, WSS, and Microsoft Passport Kerberos-related standards and drafts.
In future, also, SAML and Kerberos might be combined as a means to establish cross-realm trust.
Scott raises the use case of incorporating forwardable Kerberos tickets within attributes.
Jeff Hodges clarifies that Liberty is not doing work specific to Kerberos, but that its ongoing
SASL work can accommodate Kerberos along with other mechanisms.
Suggested next step: elaborated proposal could be discussed at upcoming focus call.
Rob questions whether this will fit into the SAML 2.0 schedule.
Mike Beach suggested that it could be useful for the SSTC to define mappings between Kerberos and SAML data elements.
Prateek introduced discussion of a pending LECP motion, containing the following elements:
· Adopt LECP solution proposal, Draft 5, 2 Jan 04
· Adopt PAOS+LECP solution proposal, Draft 1, 8 Jan 04
· Integrate into SAML 2.0 Bindings and Profiles specification
Ron questioned whether these elements were necessarily within SSTC scope; Scott believes that they are appropriate profiles to consider for
SSTC purposes. To this point, SAML has not specified that particular profiles must be implemented for conformance purposes.
Prateek observed that conformance criteria are likely to become more complex for SAML 2.0.
Tony indicated that he found the supporting use case for PAOS to be unclear.
Frederick Hirsch suggested that it allowed use with non-SOAP service providers,
and that it was compatible with operational models common in mobile environments.
Greg Whitehead commented that LECP offers particular value in multi-IDP scenarios, taking advantage of information resident on mobile terminals.
Attendees indicated that they perceive existing and emerging interest in SOAP-capable mobile terminals, and it was suggested that definition of a
standard approach for their support would be useful.
Mike McIntosh and Tony Nadalin object to the motion, particularly questioning its inclusion of PAOS.
Prateek takes a vote of attendees. 11 yes, 7 abstain, 4 no; vote passes on simple majority.
The morning session was adjourned at 12:16 PM.
WEDNESDAY PM SESSION
W-2a – SSO with Attribute exchange (Prateek)
******************************************
Several models of use. When NameIdentifier is passed – then attributes are passed
<AuthnResponse> may carry assertions with attributes statements. However ID-FF does not explicitly describe this use.
Attributes could be attributes from a second source – for example obtained from a LDAP directory – or a collection of.
ID-FF 1.2 text does not make any statements on the use of attribute statements.
Proposal revise text to explain that attribute statements may appear in AuthnResponse.
However there is an issue re attribute life-time concerns
Prateek: question are we happy with this:
Rob: sees no problem with solution
Scott: sees critical that time validity information is needed.
General discussion on whether validity period of attributes is useful or serves any purpose.
Prateek: question do attributes need a separate “time to live” values?
Hal: need a “milk”field – “use by”
ISSUE: resolve bearer token versus assertion versus attribute statement validity periods
Other aspect to adding attributes is use of pseudonyms. Still return attributes – but NameId is pseudonym.
Scott: could this be what ID_FF calls affiliation?
Prateek: However in this case there is no account linking
Prateek: need to clarify the use cases vs the ID-FF federation use cases RL Morgan: need to sort out naming space – i.e. real names
Scott: need to start examining the pair-wise case of the relationship
Prateek: key is to make sure Service provider not be involved in account linking/federation – rather the powerful Identity Provider.
Prateek: privacy issues depending on the given federation use case
Greg: If look through liberty spec
no normative text re account linking
ACTION: Prateek to describe new use cases – for liberty guys to review
(as current Liberty specs may cover those that Prateek is raising)
Prateek: question do we need to consider AuthnRequest should carry attribute query?
Tony: do we need to model the run time querying of attributes?
Prateek: not seen a business case for this
Scott: what other things could we add? There are issues going through a browser (ie. too large for URL)
Other issues: encryption of attrs; meta-data; use of std LDAP attribute names.
W4 Profile enhancements for Meta-Data (Jahan)
*******************************************
Waiting until Meta-data specs are stable – then go back to enhance profiles
W3 Meta-Data (Jahan)
************************
No work since October. Scott did a review of Liberty 1-2 meta data.
Proposal to produce new draft – based on liberty meta data. Perhaps strip out those features not required for SAML
Scott: need to consider whether features are stripped out – as some people are using them.
Prateek: are the SAML roles considered in spec?
Scott: No. Need to make sure meta data is extensible to cover unknown future SAML work.
Scott: Meta Data needs to consider perhaps roles for SAML 1.1. (versioning)
PROPOSAL: to consider ID-FF .1.2 meta data as basis of SAML 2.0 work – subject to removing any liberty web services specific.
APPROVED: unanimous
W8 – Authentication Context (John Kemp)
*****************************************
Taken a documented use case on the list. Means to get authentication characteristics – beyond authentication method.
For instance policy and operational aspects. Schema provided to express statements and whether it conforms to a particular classes.
Tony: seems to be a brand new mechanism to do this – rather than a generalized approach for this and meta data – and other stuff.
Connor: means to take existing authentication method to the next level in expressiveness.
One use case is AuthnResponse will have a URI pointer to this, rather than it carried around.
Also can issue it in a request to say that the authentication need to met this policy.
PROPOSAL: to take document as basis for work item.
APPROVED: unanimous
W9 – XML Encryption (Hal)
*******************************
Encrypt Assertion, NameIdentifier or Attribute
Not proposing to be able to encrypt it all – rather just these defined.
Excluded: arbitrary encryption; encrypted AttributeValue (i.e. have to encrypt to do the whole thing) Encrypted SubjectConfirmation
General approach:
- nameIdentifer and Attribute – Scott’s select technique
- assertion – replaces with encryptedData and optional Encrypted Key (if using PK)
Rob: what about requests?
Hal: not as critical to develop this – this as we now have SOAP encryption – and other mechanisms in the transport layer
Question: which way to go re encryption techniques.
Hal: should we consider to encrypt AttributeDesignator in requests?
Connor: do u have to separately encrypt each attribute?
Hal: yes
Scott: perhaps we should support encryption of individual statements?
ACTION: Hal to produce text to describe 3 use cases for SSTC to consider.
W14 SAML Server Trust (Jeff Hodges)
***********************************
Liberty produced a document (by John Linn). Liberty have submitted document to ID-FF – as possible basis for SAML 2.0.
Possibly add into Security Considerations and/or implementation guidelines
John Linn: trying to tease out of notation of direct and indirect trust relationship re authentications and business relationships.
Provides general guidance on trust management in a technology neutral way.
Rob: what does it miss for SAML?
John L: believes the content is very generic.
Scott: who ever signs up to it will have to address what’s missing John K: simplest way is to have standalone doc
Jeff: something he could do.
ACTION: Jeff Hodges to reformat it and recast into SAML
Tony: will need to review later to decide whether should be included. AGREED
W15 Delegation and Intermediaries (Scott and Bob Morgan)
************************************************************
Proposal: to provide a Kerberos ST to the intermediary as a SAML attribute (either as regular SSO or requested).
Tim: would want ability to carry multiple ST
John L: do we need ability to have a confirmation method for an attribute?
Bob: Need to send ST encrypted under long term session key – i.e. usual Kerberos integrity/authn overhead structure.
Tim: just trying to transport delegated credentials?
Bob: Yes.
Tim: Believes good solution
Scott: do we need to handle multiple intermediaries? Doesn’t think so - we want to go down that slippery slope – given that timescales.
Tim: perhaps contact IETF about having a “SAMLinit” – another pre-authentication method.
Ron: perhaps use SubjectConfirmation to carry ST – rather than building a special case
Scott : this use case may need AuthnRequest enhanced so that it could indicate the subject that it needs the assertion back for
(and the subject name is different from than for the AuthnRequest). Has a similar feel to that in the Kerberos Use case heard earlier.
Scott: proposes to extend so a more generalized mechanism means to request and manufacturer assertions.
Ron: is there means to get an assertion back with a given subjectConformation method? Scott; believes there should be
Ron: perhaps supply back the ST in the subjectConfirmation data
Ron: have we time to do it?
Scott: Proposes to change AuthnRequest to handle some of this.
Ron: would like to help
PROPOSAL: get basic integration of AuthnRequest/Response and then look at the various use cases to see how they can be integrated in. (Scott)
W6 – Proxied SSO (Scott)
**************************
ID-FF addresses how to chain SSO protocol across multiple identity providers.
Couple of use cases.
Liberty used authentication context to carry a list of identity providers.
Connor: Allows a use case where for instance OASIS is the proxy IdP and that would proxy through to individual companies IdP
PROPOSAL: that the elements in AuthnRequest/Response to support proxying are maintained as ID-FF as goes forward.
Afternoon session closed: 5pm
5. Thursday, February 5
===========================================================
ACTION ITEM SUMMARY FOR THE AM
ACTION: Mike make arrangements for Austin F2F (Mar 30-April 1)
ACTION: (Owner: TBD) Getting MimeType Registration
ACTION/ISSUE: (Owner: Jahan) Assigning Identifiers to SAML Entities
Rob: Convened at 9:36
Hal: Will be joining the XACML call at 10:00
Need to discuss Schedule and F2F
Mike: IBM will host in Austin
Discussion: reached concensus on Two full days Mar 30 - Mar 31 - and 2/3 days on April 1
ACTION: Mike make arrangements for Austin
09:30-11:00: Session 1 (1.5hr)
Darren Platt presentation on PingID/SourceID protocol testing/scripting engine
...slides...
Darren: Script based protocol tester - based on JMeter from Apache
Rob: Can these slides be posted?
Darren: Yes
Jeff: What is Jython?
Darren: Lets you exec Python form Java
Scott: Also allows Java from Python
Greg: Can this handle series of requests chained of the result of previous?
Darren: That is why have have custom samplers
Darren: configurable for role that system under test is playing
Greg: can require multiple systems in testing and drive from MITM
Darren: hard to do when using SSL
Prateek: should be able to run specific test with specific input and provide result log
Prateek: if this could play that early interop test role then that would help vendors
Frederick: are you planning to offer this to the TC
Darren: not fully planned out yet how this will be marketed
John: I maintain vast amount of PKI test tools for fun
John: but have not yet incorporated SAML - JMeter sounds useful
Scott: if anyone in the TC would donate testing/conformance suites it would be good/appreciated
John: We donated PKIBench for PKI testing
Scott: Would address Burton group issues
Darren: Burton group was impetus for this project
Darren: marketing group is getting excited so may not be able to donate.
Prateek: will you bring this to the RSA interop?
Darren: that is the idea - but cannot commit
...more slides...
John: do you use the standard schemas?
Darren: yes.
Scott: do the tests presume a Java implementation?
Darren: triggers are Java based but drives tests over the wire
Prateek: the TC could (if it willed it) could try to work in some way...
Darren: if the TC would bless this as the conformance testing suite for SAML
Greg: do not want to have it supercede the specs
Jeff: Doesn't think the TC blesses anything
Bob: if you want to OpenSource some of this it might work well
Darren: will take back these suggestions - thanks for input
W-19: HTTP-Based Assertion Referencing
Goal: accept solution proposal
Document: http://www.oasis-open.org/apps/org/workgroup/security/download.php/3651/draft-sstc-assertion-uri-01.pdf
Scott: posted a long time ago - not a lot to say about it - enalbes wsse:STR
Rob: is this just for bearer token?
Scott: no - no additional semantics
Scott: needed since we are Eliminating AuthorityBinding
Scott: which is currently in the WSS: SAML Token Binding
Frederick: versioning?
Scott: may look into versioning via xml namespace on mimetype
Ron: I don't understand how metadata is used here - is there a way to convey
more than the assertion id? thinking about a signature that refs an assertion - and
DNS sppofing or other attacks
Ron: can we attach something more
Scott: need to look into that - really something needed by the retriever -
yes may be reasonable to have some ref to the authority in the wsse:STR
Scott: AuthorityBinding was only giving location
Scott: wasn't saying anything about who was given the information
Mike: why is the processing different if the token is retrieved vs. provided?
Scott: it would be fruitless to apply protection on the URI
Scott: vs. protection based on the context of usage
Ron: think his issues are addressed by signing the message (with the token)
Rob: in the browser artifact profile - it is required that the requestor must be authenticated
Scott: we say in the SOAP that you SHOULD authenticated
Eve: this is out fist new binding in a while
Scott: not really a new binding
Rob: where would this be documented
Frederick: wouldn't it be in the core
Eve: I would think bindings is better - it achieves roughly the same thing as the assertion id request
Rob: but it is bound to HTTP
Greg: it is an incomplete protocol binding
Scott: don't feel strongly either way - will defer to the editors
Rob: how long will this take to get into the RFC (mime)
Scott: also for WSS need a pair of attributes: identifier of the authority id the assertion id.
Rob: if you have the URI you don't have enough?
Scott: don't thing this is the right place to do this.
Scott: some people want to use SOAP and only SOAP - need articular of what
needs to go in the STR to get the assertion id request.
Greg: would you parse the uri to get the assertion id?
Scott: you might not have a URI - if you have one you should use HTTP.
Prateek: is this an issue for us?
Scott: not for us but for the WSS people here.
Ron: it isn't an issue for me.
Frederick: I am hearing that there is no issue.
Ron: What I hear you saying is that unless we say more in WSS there
isn't going to be way to use bindings other than URI.
Frederick: it is up to WSS to address it if there is a need.
Prateek: do we need to take the step of naming SAML authorities?
Scott: yes - has been explicit in Liberty but not in SAML.
ACTION: (Owner: TBD) Getting MimeType Registration
ACTION/ISSUE: (Owner: Jahan) Assigning Identifiers to SAML Entities
MOTION: Scott moves to accept proposal, Frederick seconds
No objections, passed.
Frederick: do we want to talk SOAP now?
Mike: I am ready to do it now - or at next focus group
(as long as it could still be included in 2.0)
some discussion we may discuss at the end of the day or on focus group.
Break now: resume at 10:10
11:00-11:15: Break
11:15-12:30: Session 2 (1.15hr)
W-7: Discovery Protocol, Scott Cantor
Goal: accept solution proposal
Document: TAS
Scott: Liberty has spec for cookie with hashed provider ids
Scott: Problems if they have uris that must be url encoded.
Rob: When will you have text.
Scott: Text will come straight from liberty text.
Scott: Liberty calls it an introduction cookie - I call it discovery.
MOTION: By Scott, incorporate introduction cookie subject to appropriate
SAML changes and implementation experience, second Greg.
No objection, passed.
Other Business
Ron: Will send email to the list for each issue
NEW ISSUE: Multiple Authority Signatures on Single Assertion
Ron: 1st issue: SAML assertions carry an envelop signature with minoccurs=0
Ron: seems like an arbitrary limitation
Scott: simple part si to say more than one signature
Scott: if you want additional signature on addition claims
John: countersign of assertion in its entirety works
John: different claims should be in diff assertions and bound
Hal: could be bound by exact match on subject
Greg: might cross ref by assertion id
Ron: assertion contains multiple parts statements about subject and key binding
Ron: when sender vouches some other authority provides key binding
Hal: why not just use multiple assertions?
Prateek: still doesn't see the use case
Ron: made a drawing on the board - will send to the list
W-28b: Deprecating AuthorizationDecisionQuery and AuthorizationDecisionStatement, Prateek Mishra
Goals: Make a decision!
Document: TAS
Prateek: Told XACML to not wait for SAML before proceding
Prateek: Asked who is using it - Rebekah said NASA is - and XACML closed issue list for XACML 2.0
Hal: not sure that's true
Prateek: so won't drop these in SAML
Scott: can we import from 1.1 schema?
Hal: XACML will do XACML specific one, would prefer not to see additional features added.
Steve: they do not want to add too muc to their scope
Bob: no one here is going to write the text to complete the item
John: is the perception that it is broke?
Rob: just not powerfull enough
Hal: at the time it came XACML was not very mature and needed something simple
Scott: freezing will mean some work - copy into the schema - not the amount of work - conceptually bringing it in requires work
Rob: still need to do that if deprecating rather than removing
Scott: can we reuse existing schema rather than pull it into ours in 2.0?
Eve: to implement entire XACML to do simple auth may be too much
Hal: any PEP can only provide info that it has
Hal: deprecation could be non-specific about which version will not have it
Hal: this additional functionality could be CD in XACML before SAML 2.0
MOTION: Steve moved to freeze this functionality as is for SAML 2.0,
no further functional enhancements, with suggestion that anyone needing more functionality look at XACML,
Hal seconds
Discussion
Rebekah: isf it is not deprecated I am comfortable with the motion as is
No objections, passed.
Lunch at 12:08, resume at 1pm
Action Item Summary FOR THE PM
===================-----------
ACTION: Eve: Make a proposal that meets the W-28a* goals and discussion points.
ACTION: John H. to take on editorship of the new "baseline attributes" specification and gather text from Prateek, RLBob, and interested others.
ACTION: Eve: Add an issue to the issues list about adding prose to warn against using xsi:type on <AttributeValue>.
ACTION: Eve Add an issue to the issues list about Ron's "description of SubjectConfirmation/KeyInfo in SAML core precludes impersonation" issue.
ACTION: Eve: Put out a call for a new editor for the Implementation Guidelines document. (Ask the Liberty folks too.)
W-28a*: Attribute Usage
=======================
Goal: accept solution proposal
Latest document (from Feb 4) is at: http://www.oasis-open.org/apps/org/workgroup/security/download.php/5312/draft-sstc-attribute-03.pdf
Section 4 has the proposed modifications.
A recent XACML telecon generated a lot of discussion on this document and on the differences between SAML and XACML attribute usage.
Reviewing the proposals:
4.1: AttributeNamespace: Change this attribute explicitly to a URI that indicates how to interpret the attributes.
Could cover a lot of common schemes.
4.2: AttributeDesignatorType and AttributeDesignator: No changes needed, but some text has to come out
because later proposals have AttributeType no longer being derived from AttributeDesignatorType.
This goes with 4.3: TypedAttributeDesignatorType.
Scott: Not sure we need to go to such lengths in the schema; we can just throw some optional attributes on existing types.
Rebekah: A good example is LDAP attributes, which don't carry datatypes, whereas XACML-style attributes do.
Attempting to provide ability for someone to use AttributeNamespace and Attribute and have that be enough.
Scott: But optional XML attributes on SAML elements could be enough; if values are present, great.
There's no (XSD) schematic connection between the XML representation and the LDAP- (or whatever-)type attribute.
So you have to make this connection in prose anyway. Thus, keeping the schema simple makes sense.
Rebekah: Would the XML attribute holding the datatype go on AttributeDesignatorType, then?
Scott: Either that or AttributeType.
[Note: Proposal 4.3 suggests that it would need to be on the designator, not just the value-holding response.]
Scott: the attribute currently doesn't tell the consumer what type its value is.
Hal: XACML has an evaluation engine with type-checking, and it doesn't want to build in knowledge of specific attributes.
It should handle arbitrary ones.
RLBob: So you need schema definitions that plug in to the engine.
Scott: XACML uses built-in types plus XPath in order to achieve the goal Hal mentioned. All attributes have become self- describing.
RLBob: Does the XACML model require that attributes be annotated with type information? (All: Not sure.)
Eve: The current proposals set up two types/elements, one with required type information and one without.
Instead we could have one element with an optional datatype field.
Scott: If we're comfortable with not providing a guarantee about being able to map to XACML attributes without additional run-time logic,
that mapping could deal with both situations.
4.4: AttributeType and Attribute: Here, an <Attribute> element is proposed to contain <AttributeDesignator> rather than derive from it.
Eve: It seems a bit weird to put the typing information on an older sibling of the value, compared to the value itself or the value's parent.
Scott: The important thing is that this is type information on the attribute (regardless of choice of XML expression)
that can be used to validate that all values for the attribute are the same. Currently, SAML allows a different value for each type.
Eve: So the goals are to specify the type-as-a-URI for both attribute designators alone and for whole attributes and
enforcing (when desired) that all the values in an attribute have the same type?
All: Questions about the complexity of requiring that a returned attribute has the specified type.
There are many weak-matching scenarios.
ACTION: Eve: Propose a set of options for achieving the above (and below!) goals.
Scott: The overarching SAML<->XACML goal here is to be able to profile the SAML attribute functionality in such a way as to
make it compatible with what XACML expects. Is that right? SAML can make new optional functionality available, but to use
it successfully with XACML, it would have to be "profiled" to make some of the optional parts required for that purpose.
If XACML can then explicitly acknowledge the lack of suitability for some kinds of SAML statement that were created without regard for XACML needs.
Rob: But I thought the goal was (stronger) alignment, not
(weaker) profiling.
Scott: Pure alignment would mean always requiring the type information on attributes, though not necessarily on queries.
RLBob: But if you want to query for all attributes of a certain type, you'd need to supply type information in the query.
Eve: Note that we have a work item W-12, currently in Reassess mode, about querying attributes by type.
So we're not taking on this second use case.
Eve: We can finesse this by defining a type URI that means "the type is application-specific" and making it the default.
Then, the SAML syntax will be fully aligned, while not imposing extra burdens on SAML users who are not interested in XACML compatibility.
RLBob: Are there uses for the type information beyond XACML?
Rob: Can this be spec'd to allow for such uses?
Scott: No. The process of defining profiles of attributes should include defining whatever other details are needed to work with XACML.
4.6: ScopedAttributeValueType: This proposes a new field for holding scoping information
(e.g., department name) that people are currently (ab)using AttributeNamespace for.
It's proposed to go on a special version of the value element as a required field.
RLBob: Scope, for Shibboleth, means -- for example -- that a faculty member's name is in the value and the department is the scope.
Scott: There are many different meanings of "scope"! If we separate out what AttributeNamespace is being used for sometimes now,
let's consider that the attribute name's format.
Then we can work on all the other things that might be called "scope". This nets out to accepting proposal 4.1 but changing the
XML attribute's name to NameFormat.
Eve: +1
Irving: This feels like piling mechanisms on top of mechanisms.
Rob: In my heterogeneous environments, I might need to set up lots of different formats.
Irving: But everyone will have to support all the possible attribute name formats.
Eve: No, this will be a piece of configuration data just like all the others that we have for name identifiers etc.
And it codifies, in a more useful way than SAML V1.x did, attribute names.
Scott: So AttributeNamespace could disappear and be replaced by one or more fields that are more precise about the purpose they serve.
Scott: In Shibboleth, they have a ScopedAffiliation structure so that you can provide important information along with your attribute value (faculty...of what? the law school?) in order to give context. This seems to be a common enough need that SAML should have it.
Eve: To preserve clean separation between SAML's semantics and application-specific attribute value semantics,
SAML shouldn't have this; it should be up to people putting their own stuff inside/on <AttributeValue>.
Should we improve our schema extensibility features for this element?
Scott: We probably can't do better than xs:anyType, though maybe we need some prose with a "health warning"
that warns against using xsi:type, which requires that the extension schema be available.
ACTION: Eve: Add an issue to the issues list about adding prose as described above.
Eve: What about a field for the "source" of the attribute, in the sense that Rob and Prateek have reported using AttributeNamespace in the past?
All: Seem to generally like this idea.
John H.: This seems to work for DCE.
John H.: What if you want to supply a "friendly name" along with the GUID, the way DCE does?
Eve: Maybe we should put <xs:anyAttribute> on AttributeType. This would allow you to slap any global attribute onto
<Attribute> without needing a schema for them.
Several: Yes.
W-21: Baseline Attribute Namespaces, Bob Morgan ===============================================
Goals: accept solution proposal; decide issue of actual baseline attributes
Documents: http://lists.oasis-open.org/archives/security-services/200401/msg00060.html
http://www.oasis-open.org/apps/org/workgroup/security/download.php/4124/draft-morgan-saml-attr-x500-00.pdf
Do we need a separate document that specifies Selected Attribute Type Usage? It would be normative to the extent that,
if you use particular URIs, you must use them in the prescribed way.
This is similar in spirit to the Implementation Guidelines document, but should be separate. These would be our baseline attributes!
ACTION: John H. to take on editorship of this new document and gather text from Prateek, RLBob, and interested others.
New issue: Description of SubjectConfirmation/KeyInfo in
SAML core precludes impersonation ========================================================
Ron sent mail to the list about this today:
http://www.oasis-open.org/apps/org/workgroup/security/email/archives/200402/msg00049.html
SubjectConfirmation has a KeyInfo field that's defined to say that it's the cryptographic key held by the subject.
If we relax the restriction to force the subject to hold the key, we can handle impersonation.
Proposal: The text in SAML core should be changed to say something like this:
[line 676] An XML Signature [XMLSig] element that identifies a cryptographic key that must be demonstrated to satisfy the confirmation method.
Hal: The original wording allows additional entities to have a copy of the key, in addition to the subject.
RLBob: We would have to say "see discussion of impersonation for more information".
ACTION: Eve: Add this issue to the issues list.
W-27: Security Analysis Enhancements ====================================
Goal: report status
Scott: The primary recommendation of the IBM paper is to mandate SSL. But we're not willing to do that, though we strongly recommend it.
Prateek: This is something that the paper author may not have realized, despite our best efforts in the Bindings document.
We will carry this forward; we're doing some profile work that may impact this.
W-30: Migration Paths
=====================
Goal: report status
The group began discussing the issue of how/whether to allow a mixing of versions of assertions vs. protocol messages.
We're disinclined to allow this.
Any Other Business
==================
Eve gave a report from the editorial team. "Revision-less" forms of the documents and specs will soon be available, meaning that people will be able to bookmark permanent URLs for them. For specification documents other than schemas, there will still also be "revision-ful" forms available.
ACTION: Eve: Put out a call for a new editor for the Implementation Guidelines document. (Ask the Liberty folks too.)
The group voted to thank Hal Lockhart and BEA for their wonderful service in hosting the meeting this week. A round of applause ensured.
Adjourned at 3pm ET.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]