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: RE: [security-services] Minutes: SSTC Conference Call (September 22nd, 2009)


I want to address the comments to the SAML Name Identifier protocol contribution as given during the previous SS TC conf call. This is the corresponding part of the minutes of the Sept 22 SS TC call plus my comments in <CG> ... </CG>:

*****************************************************************
(ii) SAML Name Identifier protocol proposal (Thinh Nguyenphu/NSN)
http://www.oasis-open.org/committees/download.php/34221/SAML%20Name%20Identifier%20Protocol.ppt

Christian GŁnther from Munich, Germany gave the above presentation

SC: Why not just use federated login and persistent identifiers?

<CG>
The question is: who does the federation? Basically, there are three solutions:
Let ID_SP, ID_IDP and ID_SAML stand for identifiers of a User that identify this User at a SP, at an IDP, and on SAML protocol level (ie, an identifier shared between the SP and the IDP).
   
Solution 1: The SP does the federation / the IDP does not create an ID_SAML for the User 
The SP asks the IDP to authenticate the User, the IDP authenticates the User by means of ID_IDP and responds ID_IDP to the SP. Now, the SP has to look into his database to see, which User has ID_IDP for his ID_SP, and stores ID_SP = ID_IDP. That's, for example, how OpenID works. You tell every SP that you are john.doe@nsn.com and all SPs verify this at the IDP of nsn.com. Then they store that user-ID 3234284 (= ID_SP)is john.doe@nsn.com.

Disadvantages:
- SP has to do the federation, ie, the SP has to implement the mapping. 
- User gets traceable across services offered by the SP (privacy issue).

Solution 2: The SP does the federation / the IDP creates an ID_SAML for the User 
The SP asks the IDP to authenticate the User, the IDP authenticates the User by means of ID_IDP and then creates (or reads if already created) an ID_SAML and responds this to the SP. Still, the SP has to find out which User has ID_SAML. Nevertheless, for each SP, you can have a different ID_SAML.

Disadvantages:
- SP has to do the federation.
- Delegation (eg, vacation replacement): having to set up a delegation in each different SP separately is similar inconvenient as not having a SSO. Hence, a central point of policy management and enforcement is important.

Solution 3: The IDP does the federation
The SP asks the IDP to authenticate the User, the IDP authenticates the User by means of ID_IDP and then responds ID_SP. The SP won't have to care about ID_SAML and ID_IDP, because the IDP does the "translation".

Advantage:
- There is a central point of policy management and enforcement, namely, the IDP, who does the federation.
- The User can have more than one account at the SP. The IDP stores these multiple accounts and offers a selection to the User. This is not possible, in case the SP does the federation.

If, in case of Solution 3, the IDP does not know the User's ID_SP, then the IDP needs to send a corresponding request to the SP, who then sends ID_SP back to the IDP. This is exactly what the SAML Name Identifier protocol aims to provide. 
</CG>

RP: We have customers who have requested bulk import of identifiers
from IdP to SP (and in one case, from SP to IdP).

<CG>
In the proposed Name Identifier Protocol, it's the IdP who can request a name identifier from a SP in case the IdP receives an AuthnRequest from the SP with a name identifier unknown to the IdP for that SP. Bulk import of identifiers is a completely different thing. Our proposal does not at all intend to prevent SPs from bulk import of identifiers into IdP databases (or vice versa). Maybe, you have misunderstood our proposal in this regard.
</CG>

SC: (re second bullet on slide 3) Not clear why you need anything more
than Web Browser SSO. Why does the SP send an identifier in this case?

<CG>
Web SSO is and was an important contribution of the SAML standard. However, the service and IDP landscape has changed so that no longer one IDP provides SSO for different (dependent) SPs, but SPs may select the IDP on a per user basis. To phrase it stronger: the privacy-conscious user may want to choose to be federated or not to be included in a potential federation. Furthermore, we are not going to restrict SSO to Web applications. 
</CG> 

***********************************************************************

Christian Guenther | NSN COO RTP IE Wireline, Service Delivery and Multimedia

-----Original Message-----
From: trscavo@gmail.com [mailto:trscavo@gmail.com] On Behalf Of ext Tom Scavo
Sent: Thursday, September 24, 2009 12:36 AM
To: OASIS SSTC
Subject: [security-services] Minutes: SSTC Conference Call (September 22nd, 2009)

> Proposed Agenda SSTC Conference Call
> September 22nd, 2009, 12:00pm ET

Thomas Hardjono presiding

> Dial in info: +1 408-774-4073
> Conference code: 4480739
> Password: 72657265 (SAMLSAML)
>
> 1. Roll Call & Agenda Review

Anil Saldhana took the Roll Call.

[insert Roll Call results here]

Aliases used below:

TS = Scavo, Tom
RP = Philpott, Rob
BM = Morgan, Mr Bob
AB = Barbir, Abbie
HL = Lockhart, Hal
DD = DeCouteau, Duane
SC = Cantor, Scott
NK = Klingenstein, Mr. Nathan
PM = Madsen, Paul
FH = Hirsch, Mr. Frederick
AS = Saldhana, Mr. Anil
TH = Hardjono, Mr. Thomas

New Action Items

- Port the SSTC Work Summary to the wiki [HL]
- Create new Working Drafts of the HoK Profiles [TS]
- Produce CD version of Identity Assurance profile and update the wiki [BM]
- Produce CD version of Condition for Delegation Restriction [SC]
- Investigate and report on CARML. [HL]
- Produce CS version of Text-based Challenge/Response profile [AS]
- Include the question whether or not to increase the frequency of meetings [TH]

> 2. Need a volunteer to take minutes

TS volunteered to take minutes

> 3. Approval of minutes from last meeting (25 August 2009):
> † http://www.oasis-open.org/apps/org/workgroup/security/email/archives/200908/msg00083.html

RP moves to accept the minutes, BM seconds. Motion carries unanimously.

> 4. AIs & progress update on current work-items:
>
> †(a) Current electronic ballots: none

SAML Status Presentation for the ITU-T

AB asked HL for a SAML update to be presented to the ITU-T. (There's a
formal arrangement between OASIS and ITU-T such that the latter
normally reviews and adopts OASIS Standards.) HL prepared a
presentation:

http://www.oasis-open.org/committees/download.php/34320/SAML%20Status%20for%20ITU-T.ppt

AB will actually make the presentation to ITU-T.

As a by-product, HL produced a work summary for the SSTC:

http://www.oasis-open.org/committees/download.php/34321/Post%20SAML%202.0%20Profiles.doc

Should this be included in the wiki? If so, at what level of visibility?

> †(b) Status of past (closed) ballots:
>
> † † † XSPA - spec has been submitted to OASIS for approval as Full Standard.

DD reports that the profile has been submitted to OASIS tc-admin for
OASIS Standard ballot. The familiarization period is anticipated to
begin on Oct 1, 2009.

DD also reports that both wikis have been updated.

> † † † SAML V2.0 Attribute Extensions Version 1.0
> † † † SAML V2.0 Metadata Extension for Entity Attributes Version 1.0
> † † † SAML V2.0 Metadata Interoperability Profile Version 1.0

Minor errata were incurred as these documents transitioned from CD to
CS. SC has no plans to bring these documents back to the Working Draft
stage to correct these non-substantive errata.

SC posted relevant attestations to the mailing list:

http://lists.oasis-open.org/archives/security-services/200909/msg00035.html

If there any other implementations of these (or any other CS) specs,
please submit a formal attestation so these documents can move
forward.

> † † † SAML V2.0 Holder-of-Key Web Browser SSO Profile Version 1.0 as a CS
> † † † SAML V2.0 Holder-of-Key Assertion Profile Version 1.0

Similar to the previous three documents, TS reports that these two
documents also incurred errata as they were transitioned from CD to
CS. This includes a normative reference from the Holder-of-Key Web
Browser SSO Profile (CS) to the Holder-of-Key Assertion Profile (CD).
The only way to correct this (and other) errata is to bring these
documents back to Working Draft. NK agrees we should do this.

Editors take note: In the future, OASIS tc-admin will transition
documents from CD to CS. This means that all modifications to the CS
version (apart from dates and version numbers) must be anticipated in
advance.

> †(c) 15-Day review of sstc-saml-approved-errata-2.0-draft-49 (action for Hal)

This document was previously ost, then found. An announcement is imminent.

> †(d) Progress on getting Jira instance for SSTC (Scott).

No update.

> †(e) Dwayne to add a page for the XSPA page in the SAML wiki.
> † † http://www.oasis-open.org/apps/org/workgroup/security/ballots.php

DD reports this is done:

http://wiki.oasis-open.org/security/XSPASAML2Profile

> †(f) Kerberos related items (Josh):
> † † - Kerberos Attribute profile (draft-02):
> † † † http://www.oasis-open.org/apps/org/workgroup/security/download.php/34160/sstc-saml-attribute-kerberos-02.odt
>
> † † - Kerberos Subject Confirmation Method (draft-00):
> † † † http://www.oasis-open.org/apps/org/workgroup/security/download.php/34161/sstc-saml-kerberos-subject-confirmation-method%2000.odt

SC wonders if this new Confirmation Method (CM) is potentially
controversial. (The spec proposes a new CM rather than using the
existing holder-of-key CM.) It is likely WSS implementations may
break. Also we seem to be setting a precedent, which is not bad per
se, but we need to consider this proposal carefully.

For background information on issue, please consult the following
threads of discussion:

http://lists.oasis-open.org/archives/security-services/200906/msg00027.html
http://lists.oasis-open.org/archives/security-services/200907/msg00017.html
http://lists.oasis-open.org/archives/security-services/200908/msg00016.html

Further comments to the list, please.

> †(g) Expressing Identity Assurance profile for SAML2.0 (LOA) †(Bob Morgan)
> † † http://www.oasis-open.org/committees/download.php/34277/sstc-saml-assurance-profile-draft-01.pdf

BM uploaded a new version of this document (above). Some sections were
moved, an example was added, and other tweaks were made. No normative
changes were made, however. BM believes this document is ready for CD.
So moved (by BM). PM seconded. No objections. Motion caries
unanimously.

> †(h) Delegation Condition Extension Profile (Scott)

SC uploaded a new version of this document:

http://www.oasis-open.org/committees/download.php/34357/sstc-saml-delegation-cd-02.pdf

SC created a new introduction and included some new diagrams that
describe multiple actors. The goal was to motivate the use cases. SC
would like to get this document back out to public review. No
substantive changes were made, however. SC moves to take the document
to CD. BM seconds. No objections. Motion carries.

Next step is to request a CS ballot. Is the schema correct? Yes, all
schema fragments are valid. Are normative refs synchronized? There are
no xrefs, so this shouldn't be a problem. SC moves the SSTC request a
CS ballot. BM seconds. No objections. Motion carries.

PS. Don't forget to include the voting member list in the CD,
otherwise there won't be an opportunity to do this as the document is
automatically transitioned to CS.

> 5. New work items:
>
> †(i) SAML Attribute Management protocol proposal (Thinh Nguyenphu/NSN)
> † † http://www.oasis-open.org/committees/download.php/34222/SAML%20Attribute%20Mgt%20Protocol.ppt

Thinh Nguyenphu gave the above presentation. He reviewed the use cases
(slide 2) and proposed a new SAML Attribute Management Protocol (slide
4).

HL: In what sense is the account at the SP transient? Answer:
Basically, we have a stateless SP so we would like to save attributes
back to the IdP.

HL: Do the two use cases look the same to the IdP? Answer: Yes

SC: As a point of clarification, the SSTC won't modify the SAML Standards.

HL: Some comments were posted online:

http://lists.oasis-open.org/archives/security-services/200909/msg00016.html

HL: Recommends CARML (Liberty) for these use cases. Perhaps CARML
should be contributed to the SAML TC?

BM: All of CARML or just the relevant portions? (This of course would
be up to the SSTC.)

SC: ID-WSF solves these use cases as well.

SC: Are there IPR issues associated with these use cases?

FH: Can you solve this problem without the complexity of full ID-WSF?

General consensus of the SSTC is that update capability is useful, but
this isn't necessarily the job of this TC. We should leverage other
solutions (CARML, SPML, etc.) if indeed they are relevant.

> †(ii) SAML Name Identifier protocol proposal (Thinh Nguyenphu/NSN)
> † † http://www.oasis-open.org/committees/download.php/34221/SAML%20Name%20Identifier%20Protocol.ppt

Christian GŁnther from Munich, Germany gave the above presentation

SC: Why not just use federated login and persistent identifiers?

RP: We have customers who have requested bulk import of identifiers
from IdP to SP (and in one case, from SP to IdP).

SC: (re second bullet on slide 3) Not clear why you need anything more
than Web Browser SSO. Why does the SP send an identifier in this case?

At this point, we're taking it to the list for further discussion.

> 6. Assorted threads on saml-dev/comment list
> † - Oasis Identity Management 2009 (29-30 Sept, NIST, Gaithersburg, MD)
> † † http://events.oasis-open.org/home/forum/2009/registration

This is actually an OASIS event and OASIS members are encouraged to attend.

New business:

Scott uploaded a new errata draft:

http://www.oasis-open.org/committees/download.php/34096/sstc-saml-errata-2.0-draft-50.pdf

Next call four weeks from today: Tuesday, October 20, 2009

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 



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