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: [security-services] Draft minutes for Tuesday PM

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.

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