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] Proposed Agenda for SSTC Conference Call,Dec 23

I would also like to remind you that a LECP need not be a proxy, but can be a client that knows how to find the appropriate identity provider.

regards, Frederick

Frederick Hirsch
Nokia Mobile Phones

-----Original Message-----
From: ext Skytta Timo (NMP-MSW/Espoo) [mailto:timo.skytta@nokia.com]
Sent: Tuesday, December 30, 2003 5:00 AM
To: security-services@lists.oasis-open.org
Subject: RE: [security-services] Proposed Agenda for SSTC Conference Call,Dec 23


It seems we are going back to same issues time after time, will we ever get to
productive technical work ?

Regarding your issues below:

I explained in the email below the need, and asked you to come back with exact info
as to why the current SAML profiles work for my (mobile) industry.


More comments inline:

On Tue, 2003-12-30 at 04:43, ext Anthony Nadalin wrote:

I have a couple of issues:

(1) seems like a profile that another group like OMA takes up (but have not seen a requirement there either)

OMA Mobile Web Services Release 1.0 is normatively referring to Liberty ID-FF 1.1, which includes LECP, and the requirements
justifying this work in OMA include ones that identify LECP. See also my previous email about this:


(2) seems to rely on a "proxy" that seems to be out of scope of SAML and thus seems like issue #1 may be where the profile and proxy can be provided

Based on what you state a proxy is out of scope for SAML ? Isn't SAML chartered to solve a certain set of technical/business issues based
on agreed business/technical use cases ?

It is upto the SS TC members to define what is a proper technical solution to a certain valid business/technical use case

LECP relies on a proxy role that can be implemented in current Mobile WAP/HTTP gateways/proxies to support existing mobile
handsets, and for future handsets it will be implemented in the handset SW-platform.

Since LECP is not mobile specific, even though it solves our problems reliably, whilst the other SAML profiles don't, it is still a generic spec
and Nokia feels it is important it to be part of a generic XML-specification.

If OMA later wants to profile SAML 2.0 it is their choice, but with very generic issues such as the ones addressed in SAML, Nokia feels that
industry is better served by a generic spec implemented in as many platforms as possible.

(3) seems there is nothing specific to SAML (value add) thus seems like issue #1 may be where the profile best done

Is totally disagree. You seem to think that enabling SAML to be used as a key building block within Mobile industry is not good ?

Browser Arctifact/POST profiles (and similar profiles in other private papers) will NOT work reliably for any existing mobile handsets, and due
to the time it takes until a new generation of mobile handsets with less limitations are used by mass market consumers, or even enterprises, it
takes several years until SAML or other similar efforts would become useful for Mobile industry.

The extensive pilot testing done by several Liberty members shows that ID-FF 1.x is stable, reliable, deployable and solves the technical
and business issues for the mobile industry.

The benefits for SAML are:

- Become the de facto standard for Federated Identity and SSO in Mobile Industry
  This exposes SAML specs to hundreds of millions of consumer/enterprise customers, I fail to see why SAML wouldn't be
- Integrate with emerging Mobile solutions based on Liberty ID-FF 1.1 (or later OMA MWS Rel 1.0). These specs will build the
  momentum and need for SAML 2.0
- Show that the generic technical needs of very different industries can be addressed by a standardization body, i.e. move away from
   the "silo" type of specs (specific to a industry) into more generic specs.

Since you seem to object  just about every work item that is somehow Liberty related, you also seem to be making a statement
that those companies who work in Liberty, which is an open organization for any company to participate, do not know either their
own business or technical requirements, and on top of that their don't have a clue on how to create a proper technical solution for the
problems they have identified.

I would like to see you to provide some real info or facts as to:

- why are the business/technical use cases not valid
- why are the technical solutions proposed for discussion (remember there is still a long way to a final SAML 2.0 spec)
   not technically valid. I would be more than happy to see technical counter proposals or contributions from IBM addressing
   the technical/business issues we have discussed. So far I have only seen process related contributions.

Rgds Timo

PS. Happy new year 2004 to all on this list !

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