Re: [pki-tc] Question about PKI and Federated Identity

["Anders Rundgren" <anders.rundgren@telia.com>]

I believe you have to look on a number of different scenarios
here.  Liberty touted "Federation" as a primary thing,
with examples such as airlines and car rental companies
sharing customers etc.  Although a nice idea it has this
little snag that there are many competing airlines and
car rental companies, making this kind of federation
rather unlikely to happen on a major scale.

The Shibboleth scenario where associates of organizations
are only are administered by their own organizations seems
like a much more logical scenario.  The same scenario is
also highly applicable to B2B-authentication.  For these
kind of scenarios client-side PKI is fairly deficient as
you need role-based authentication and numerous of
attributes supporting the business relation in most cases.
However, the client must of course authenticate to his
own home-base (attribute authority), and there client-side
PKI would be highly appropriate.

VISA's 3D Secure is (principle-wise) also very similar
to SAML, making such schemes de-facto standards for
creating Internet-sized org-to-org security.

FI also supports privacy in a way PKI don't do too well.

In my opinion one should also study how organizations
secure messages between each other as this is another
area of confusion and disagreement.

Considerably more on this exciting subject is available at:
http://www.x-obi.com/OBI400/pki4org.pdf

SAML/Liberty can also be used to create TTP-style
ID-providers and the UK government is apparently
doing that.

Anders


----- Original Message ----- 
From: "Steve Hanna" <Steve.Hanna@Sun.COM>
To: "PKI TC" <pki-tc@lists.oasis-open.org>
Sent: Wednesday, March 17, 2004 20:45
Subject: [pki-tc] Question about PKI and Federated Identity


PKI TC members,

Here is an email that was sent to the pki-tc-chair
alias with a comment about Federated Identity
and PKI. If you would like to reply to this,
feel free to do so.

I told Mr. Kershaw that I would pass on this
note to the PKI TC for comment. I also told
him about my personal opinion, which is that
Federated Identity (FI) standards are useful
and complementary to PKI. FI can use PKI to
authenticate users (or not). FI typically uses
PKI to secure communications between trust
authorities (but not always). FI can reduce
the need for large PKIs by allowing organizations
to recognize each others' credentials (although
many of the same hard issues arise, like
defining levels of trust and liability).

So I don't see FI as a panacea or a replacement
for PKI. Rather, I see them as complementary.
However, that's just my opinion. Please feel
free to share yours. And feel free to cc the
pki-tc alias on your response. I expect we'd
all be interested in how this discussion proceeds.

Thanks,

Steve

-------- Original Message --------
Subject: [pki-tc-chair] Widespread adoption of PKI
Date: Wed, 10 Mar 2004 06:27:43 +0000
From: Mark Kershaw <mkersh@hotmail.com>
To: pki-tc-chair@lists.oasis-open.org

Dear sir/madam,

I have had a brief look through your action plan and was surprised that 
there was no mention of adoption of Federated Identity standards as a
way 
forward for the widespread adoption of PKI.

Admitedly at the moment these FI standards (Liberty Alliance, Saml, 
WS-Federation) do not cater for services like digital signatures but I'm 
sure this will come in time.

As a technical architect I know the cost of integrating a PKI solution
into 
a product. Federated Identity if it becomes mainstream will solve most
of 
these problems. From a solution providers perspective you should
literally 
beable to drop any Identity Providers solution into your offering.

Any comments?

Regards

Mark

_________________________________________________________________
Find things fast with the new MSN Toolbar - includes FREE pop-up
blocking! 
http://clk.atdmt.com/AVE/go/onm00200414ave/direct/01/


To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/pki-tc-chair/members/leave_workgroup.php.