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@kantarainitiative.org <wg-fi-bounces@kantarainitiative.org> To: Patrick Harding <pharding@pingidentity.com> Cc: dg-bctf@kantarainitiative.org <dg-bctf@kantarainitiative.org>; FI WG <WG-FI@kantarainitiative.org>; Curry Patrick <patrick.curry@federatedbusiness.org>; Kantara Leadership Council Kantara <LC@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@ve7jtb.com<mailto:ve7jtb@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@kantarainitiative.org<mailto:WG-FI@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@pingidentity.com<mailto:pharding@pingidentity.com><mailto:adurand@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>