Subject: [OAUTH-WG] draft-ietf-oauth-assertions-06

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 8 Oct 2012 15:12:42 +0300

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 same argument 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?

---

From: Mike Jones <[email-masked]>
Date: Tue, 9 Oct 2012 00:05:25 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo)
Sent: Monday, October 08, 2012 5:13 AM
To: [email-masked]
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.

*       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 same argument 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?

---

From: Chuck Mortimore <[email-masked]>
Date: Mon, 8 Oct 2012 17:14:12 -0700

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:

                                                                -- Mike

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo)
Sent: Monday, October 08, 2012 5:13 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [OAUTH-WG] draft-ietf-oauth-assertions-06

Hi all,

*       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

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Brian Campbell <[email-masked]>
Date: Tue, 9 Oct 2012 08:34:01 -0600

As a vendor we can't really share deployment particulars of our customers.
But we've had product support for the SAML authorization grant for some
time now. So I can point to some online documentation for the support we
provide in our PingFederate product as an AS,
http://documentation.pingidentity.com/display/PF610/Configuring+an+OAuth+SAML+Grant+IdP+Connectionand
http://documentation.pingidentity.com/display/PF610/Grant+Types#GrantTypes-1218708as
well client side support for obtaining suitable SAML tokens via
WS-Trust
or brokering the OAuth request directly to the AS,
http://documentation.pingidentity.com/display/PF610/STS+OAuth+Integration

Off hand I also remember that Google released some support for JWT grants
in March. My colleague, the venerable John Fontana, wrote about that on
ZDnet,
http://www.zdnet.com/blog/identity/google-dumps-keys-passwords-secures-services-with-standards-certs/342

On Mon, Oct 8, 2012 at 6:14 PM, Chuck Mortimore
<[email-masked]>wrote:

> 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
>
>
> 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:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Tschofenig, Hannes (NSN - FI/Espoo)
> *Sent:* Monday, October 08, 2012 5:13 AM
> *To:* [email-masked]
> *Subject:* [OAUTH-WG] draft-ietf-oauth-assertions-06****
> ** **
>
> Hi all,****
>
> of the discussions had been reflected in this recent draft update.****
>
> 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****
>
> tests? If so, what specifically had been tested?****
> [email-masked]
> [email-masked]