Our use-cases are pretty straightforward - customers want to perform server to server integration tasks without passwords.
We use the SAML and JWT assertion profiles to enable them to authenticate to our system without having a password for the service principal they're trying to act as. Sometimes this is for security purposes ( customer doesn't want to use passwords ), and sometimes it's for scale purposes ( customer is building some sort of hub-spoke integration architecture where passwords and their associated distribution and maintenance simple won't scale ) While SAML is predominantly used for Web SSO today, it is used and quite applicable in these types of scenarios. The easy way to picture what we're doing is deploying a Security Token Service similar to WS-Trust, but without all the baggage of WS-Trust....you can simply post Assertions to our Token Endpoint and we can exchange that for oauth access tokens. -cmort On Oct 8, 2012, at 5:05 PM, Mike Jones wrote: Yes, OpenID Connect uses the Assertions spec and the JWT Assertion Profile. See uses of [OAuth.JWT] in http://openid.net/specs/openid-connect-messages-1_0.html. It is used for both client_secret_jwt and private_key_jwt client authentication. Per http://osis.idcommons.net/wiki/Category:OC4_Solution, there are a dozen publicly declared OpenID Connect implementations (admittedly some incomplete), and substantial interop testing is under way, per http://osis.idcommons.net/wiki/OC4:OpenID_Connect_Interop_4. Brian Campbell and Chuck Mortimore may be able to provide similar data for use of the SAML Profile. -- Mike From: oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org> [mailto:oauth-boun...@ietf.org] On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) Sent: Monday, October 08, 2012 5:13 AM To: oauth@ietf.org<mailto:oauth@ietf.org> Subject: [OAUTH-WG] draft-ietf-oauth-assertions-06 Hi all, I took a look at version -06 of the assertions draft to see whether some of the discussions had been reflected in this recent draft update. I was hoping that there is a bit more explanation of the use case that motivates the work. Unfortunately, the update does not contain anything along these lines. For example, the use cases could clarify the following aspects: * Why we need these new client authentication mechanisms? This is not necessarily a way in which SAML is used (at least not to my knowledge). If I understood it correctly then the new client authentication mechanism is only used between the client and the authorization server but not with the resource server. Did I correctly read the document? * Then, there is the assertion usage for authorization grants. There, one could argue that the use case is to interwork with existing SAML infrastructure. The sameargument does not apply for the JSON based format since there is no transition need (IMHO at least). Ciao Hannes PS: For the shepherd write-up I have to attach information about the implementation and deployment experience. Is there anything I could mention? Has this specification been part of the OpenID Connect interop tests? If so, what specifically had been tested? _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
