Re: [OAUTH-WG] Building on the protocol in the draft “OAuth 2.0 Token Exchange: An STS for the REST of Us” to include Authentication Tokens

zation: AOL LLC Date: Wednesday, April 20, 2016 at 1:36 PM To: "Fregly, Andrew" mailto:afre...@verisign.com>>, John Bradley mailto:ve7...@ve7jtb.com>>, "oauth@ietf.org<mailto:oauth@ietf.org>" mailto:oauth@ietf.org>> Subject: Re: [OAUTH-WG] Building on t

Re: [OAUTH-WG] Building on the protocol in the draft “OAuth 2.0 Token Exchange: An STS for the REST of Us” to include Authentication Tokens

s access and id tokens bask to the Mobile app (following the code or other flow). Am I missing something? Thanks, George On 4/20/16 10:31 AM, Fregly, Andrew wrote: Hi George, You fully captured one of the options we have been contemplating. I didn’t propose this flow because I was looking

Re: [OAUTH-WG] Building on the protocol in the draft “OAuth 2.0 Token Exchange: An STS for the REST of Us” to include Authentication Tokens

his way whether the data providers are validating the access_tokens locally or using introspection they can obtain the IdP the user used and apply their own authorization rules. The user is only required to do one authorization flow for the client that is managed by the Authorization Server. T

Re: [OAUTH-WG] Building on the protocol in the draft "OAuth 2.0 Token Exchange: An STS for the REST of Us" to include Authentication Tokens

u sited are relevant here. I guess you are talking about RFC7521-7523 ;-) RFC7251 AES-CCM Elliptic Curve Cryptography (ECC) Cipher Suites for TLS RFC7252 The Constrained Application Protocol (CoAP) RFC7253 The OCB Authenticated-Encryption Algorithm 2016年4月20日(水) 5:34 Fregly, Andrew mailto:afre...@ver

Re: [OAUTH-WG] Building on the protocol in the draft “OAuth 2.0 Token Exchange: An STS for the REST of Us” to include Authentication Tokens

need a diagram. John B. On Apr 19, 2016, at 5:05 PM, Fregly, Andrew mailto:afre...@verisign.com>> wrote: Thanks for your response John. I also got a good response from Brian Campbell and appreciate that. I will respond separately to Brian’s response as I think it would keep things clea

Re: [OAUTH-WG] Building on the protocol in the draft “OAuth 2.0 Token Exchange: An STS for the REST of Us” to include Authentication Tokens

ted IdPs to choose from. The user will then be redirected to SomeOrg Inc. IdP, authenticate and the data provider will have the authorization and recent authentication they can validate. Is the user/data flow more complicated than this? Thanks, George On 4/19/16 4:05 PM, Fregly, Andrew wrote: Th

Re: [OAUTH-WG] Building on the protocol in the draft "OAuth 2.0 Token Exchange: An STS for the REST of Us" to include Authentication Tokens

expected seem to suffice your needs. Am I missing something? On Wed, Apr 20, 2016 at 05:05 Fregly, Andrew mailto:afre...@verisign.com>> wrote: Thanks for your response John. I also got a good response from Brian Campbell and appreciate that. I will respond separately to Brian’s response a

Re: [OAUTH-WG] Building on the protocol in the draft “OAuth 2.0 Token Exchange: An STS for the REST of Us” to include Authentication Tokens

token from a idP and then have the client exchange that assertion for another token? John B. On Apr 19, 2016, at 1:18 PM, Fregly, Andrew mailto:afre...@verisign.com>> wrote: I have a use case where a client application needs to authenticate with a dynamically determined Identity Provider that

Re: [OAUTH-WG] Building on the protocol in the draft “OAuth 2.0 Token Exchange: An STS for the REST of Us” to include Authentication Tokens

openid.net/wg/connect/ Unfortunately I can’t quite make out what you are trying to do. It sort of sounds like you want an id_token from a idP and then have the client exchange that assertion for another token? John B. On Apr 19, 2016, at 1:18 PM, Fregly, Andrew mailto:afre...@verisign.com>

[OAUTH-WG] Building on the protocol in the draft “OAuth 2.0 Token Exchange: An STS for the REST of Us” to include Authentication Tokens

I have a use case where a client application needs to authenticate with a dynamically determined Identity Provider that is separate from the Authorization Service that will be used issue an access token to the client. The use case also requires that as part of authorization, the client provides