[KI-LC] [WG-FI] PKI vs. Non-PKI based trust models

Alterman, Peter (NIH/CIT) [E] altermap at mail.nih.gov
Mon Mar 14 13:47:45 EDT 2011


Absolutely correct – BAE is technology-neutral, in fact.

From: Bucci, Debbie (NIH/CIT) [E]
Sent: Monday, March 14, 2011 1:45 PM
To: 've7jtb at ve7jtb.com'; 'pharding at pingidentity.com'
Cc: 'dg-bctf at kantarainitiative.org'; 'WG-FI at kantarainitiative.org'; 'patrick.curry at federatedbusiness.org'; 'LC at kantarainitiative.org'
Subject: Re: [WG-FI] PKI vs Non-PKI based trust models

There is room for both front and back end attribute release mechanisms.

I do not think the BAE is exclusively PIV only.

________________________________
From: wg-fi-bounces at kantarainitiative.org <wg-fi-bounces at kantarainitiative.org>
To: Patrick Harding <pharding at pingidentity.com>
Cc: dg-bctf at kantarainitiative.org <dg-bctf at kantarainitiative.org>; FI WG <WG-FI at kantarainitiative.org>; Curry Patrick <patrick.curry at federatedbusiness.org>; Kantara Leadership Council Kantara <LC at kantarainitiative.org>
Sent: Mon Mar 14 13:27:45 2011
Subject: Re: [WG-FI] PKI vs Non-PKI based trust models
Yes that is a popular solution inside Enterprises and some Gov.

The problem is scalability and user consent.    In the US PIV BAE case the permission to make a SAML query on the  identifier (FASC-N) in the certificate is on a agency by agency basis.   There is no way for the owner agency to know if the requester needs the info of if the user is asking for access.

Given the high level of trust between agencies,  they tend not make info available.   The problem is as the distance between the parties gets larger, releasing information without some sort of user confirmation becomes more problematic.

In those cases we have discussed using SAML Holder of Key between organizations to be able to provide more control over attribute release while maintaining the security of the session binding to the card keys.

There are multiple approaches.

John B.
On 2011-03-14, at 11:47 AM, Patrick Harding wrote:


+1

We have a number of customers who use PKI (for AuthN) in combination with SAML (for AuthZ). SAML is used to move user attributes from the IdP to the SP to allow the SP to make authorization decisions. These attributes are stored in a Directory at the IdP rather than being 'baked into' the users certificate. The main reason seems to be an expectation that these attributes will change much more often than the users certificate will be renewed. (And yes in this context SAML Assertions do start to sound an awful lot like 'attribute certiicates').
On Mon, Mar 14, 2011 at 10:50 AM, John Bradley <ve7jtb at ve7jtb.com<mailto:ve7jtb at ve7jtb.com>> wrote:
It is a complicated almost religious discussion.

I don't think assertions (SAML, openID) or PKI client Auth are going away any time soon.

The trust model and technology are slightly disjoint discussions.

People can use smartcards with self issued certificates and SAML providers can sign assertions with certificates with roots ross certified to specific PKI bridges.

This is probably more a FIWG discussion.

That is where the rubber hits the road for the more complicated cross federation issues, when it comes to trust models.

For certificates vs assertions there is a privacy related issue.  Depending on the use case.
For Defence intelligence and Police credentials there may be no expectation of privacy or anonymity or privacy when your credential is used.

However many privacy people in the Citizen to Gov use case want to stop correlating identifiers across sites.  In some case there is a legal requirement for this.

I helped start Xcert software (now RSA KeyOn) 12 years ago to work on federated identity issues using PKI client Auth.  Why PKI failed in the consumer/internet space is a big topic.

In the US FICAM anticipates the vast majority of external credentials it will accept to be assertion based.

I should also mention that u-prove (zero knowledge prrof) cryptography contains elements of both certificates and assertions.   I have limited expectations for any short term traction on that however.

The reality is that the main driving force on the internet is access to API, and attributes.   SSO is just something that is going along for the ride.

The US Gov PIV card deployment needs BAE (SAML attribute query) to retrieve attributes and be useful.  (perhaps overstated)

Lets discuss how you want to separate the issues.  If we tackle them all together we will probably get nowhere.

John B.

On 2011-03-14, at 8:08 AM, Rainer Hörbe wrote:

John, Patrick and I had a discussion about the pros and cons of federation models based on credentials versus assertions. The attached document is a preliminary result with conclusions like

 *   PKI and non-PKI federation models need to be combined in most cases at higher LoA
 *   To implement a federation an RFC 3647-style policy is insufficient; A more complete Trust Framework is needed
 *   Whereas the Higher Education sector favors brokered trust, e-Government and Industry prefer the PKI approach. But it is not a question of one way or the other.

Request for feedback:
I wonder where this discussion should be homed. FIWG, BCTF and TFMM are related, and it is also an extrakantarian issue. Any interest to take over this discussion?

- Rainer
<pki vs non-pki.pdf>


_______________________________________________
WG-FI mailing list
WG-FI at kantarainitiative.org<mailto:WG-FI at kantarainitiative.org>
http://kantarainitiative.org/mailman/listinfo/wg-fi



--
Patrick Harding  |  CTO
PingIdentity  |   www.pingidentity.com<http://www.pingidentity.com/>
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
O: +1 781.373.4859   M: +1 617.304.0659
Email: pharding at pingidentity.com<mailto:pharding at pingidentity.com>
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Connect with Ping
Twitter: @pingnewsflash
LinkedIn Group: Ping's Identity Cloud
Facebook.com/pingidentitypage<http://Facebook.com/pingidentitypage>

Connect with me
Twitter: @pingcto
LinkedIn.com/in/patrickharding<http://LinkedIn.com/in/patrickharding>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kantarainitiative.org/pipermail/lc/attachments/20110314/4be0a6d4/attachment-0001.html 


More information about the LC mailing list