[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes from F2F, Feb 3-5, 2004
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
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
Conor: 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
SSTC F2F meeting
Afternoon of Friday, 5 February 2004
Action Item Summary
===================
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]