Tony
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:]
Sent: Tuesday,
December 30, 2003 5:00 AM
To:
Subject: RE:
[security-services] Proposed Agenda for SSTC Conference Call,Dec
23
Anthony,
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.
http://lists.oasis-open.org/archives/security-services/200310/msg00069.html
More
comments inline:
On Tue, 2003-12-30 at 04:43, ext Anthony Nadalin
wrote:
Frederick,
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:
http://lists.oasis-open.org/archives/security-services/200311/msg00108.html
(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
interested.
- 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 !
