Day 2 of the Cloud Identity Summit kicked off w/ Ping Identity's CEO, Andre Durand, discussing the importance of identity and the need for us to come together as a community to discuss it in the context of cloud computing (similarly to what other thought leaders said at RSA). He handed it off to Gunnar Peterson who said that there are four fundamental technologies necessary to enable broad adoption of cloud computing:
Eve Maler picked up on this theme in her talk on User Managed Access (UMA), a protocol for authorization that's being incubated by Kantara. In addition to birthing new standards, this organization, Pamela Dingle explained after Maler's talk, is also a Trust Framework Provider (TFP). This and similar organizations are essentially abstractions around IdPs. The US Government is defining profiles of certain protocols (e.g., Info Card, OpenID, etc.), and stipulating that TFPs must ensure that all IdPs that they vouch for conform to these profiles. (I imagine that attribute contracts are also specified, but I don't recall Dingle saying that.) The output of these TFPs is metadata which is analogous to a Certificate Revocation List (CRL) in PKI. Because the "CRL" can be traced from the TFPs back up to the US Government, RPs can pick and choose IdPs willy nilly knowing that they are all reputable and capable of asserting someone's identity.
This abstraction would have come in handy during Lee Hammond's talk that he did w/ Brian Kissel. In it, Hammond spoke about how his record label is using Janrain's Engage product (formerly RPX) to shield his Web apps from the assortment of protocols supported by the IdPs he relies on. Using Janrain's identity protocol mediation service, music fans are able to seamlessly login once to the Web sites of multiple musicians on his label. During his presentation, Hammond didn't want to give a live demo because Twitter was giving him a fail whale earlier in the day. If his protocol aggregator depended on the TFP instead of the actual IdP (Twitter in this case), it may actually (e.g., if Hammond configured it to do so), fail over to some other comparable IdP.
There were a lot of other great things discussed during the day. If you want to know more, drop me a line. Also, be sure to check back here tomorrow for the final report on what's happening in the cloud identity community. It's exciting stuff!
- Security Token Services (STSs),
- Policy Enforcement Points (PEPs) and Policy Decision Points (PDPs),
- Gateways, and
- Monitoring.
Eve Maler picked up on this theme in her talk on User Managed Access (UMA), a protocol for authorization that's being incubated by Kantara. In addition to birthing new standards, this organization, Pamela Dingle explained after Maler's talk, is also a Trust Framework Provider (TFP). This and similar organizations are essentially abstractions around IdPs. The US Government is defining profiles of certain protocols (e.g., Info Card, OpenID, etc.), and stipulating that TFPs must ensure that all IdPs that they vouch for conform to these profiles. (I imagine that attribute contracts are also specified, but I don't recall Dingle saying that.) The output of these TFPs is metadata which is analogous to a Certificate Revocation List (CRL) in PKI. Because the "CRL" can be traced from the TFPs back up to the US Government, RPs can pick and choose IdPs willy nilly knowing that they are all reputable and capable of asserting someone's identity.
This abstraction would have come in handy during Lee Hammond's talk that he did w/ Brian Kissel. In it, Hammond spoke about how his record label is using Janrain's Engage product (formerly RPX) to shield his Web apps from the assortment of protocols supported by the IdPs he relies on. Using Janrain's identity protocol mediation service, music fans are able to seamlessly login once to the Web sites of multiple musicians on his label. During his presentation, Hammond didn't want to give a live demo because Twitter was giving him a fail whale earlier in the day. If his protocol aggregator depended on the TFP instead of the actual IdP (Twitter in this case), it may actually (e.g., if Hammond configured it to do so), fail over to some other comparable IdP.
There were a lot of other great things discussed during the day. If you want to know more, drop me a line. Also, be sure to check back here tomorrow for the final report on what's happening in the cloud identity community. It's exciting stuff!
