Subject: [OAUTH-WG] HOTK/POP and id_tokens

From: Lewis Adam-CAL022 <[email-masked]>
Date: Thu, 15 May 2014 19:31:58 +0000

Hi,

Does the WG plan to include OIDC id_tokens within the scope of the HOTK/POP work?  I've scanned through all of the existing HOTK/POP drafts and none make any reference to id_tokens.  Is this effort going to be scoped strictly to access tokens?

I am at a cross road right now where I'm considering using id_tokens in lieu of access_tokens within our API calls (as we were never using the access tokens for authorization anyway, but rather had profiled the AT to look identical to an id_token for authentication, and now that OIDC is complete ... you get the idea), ... BUT ... we want HOTK/POP badly, and I don't want to design ourselves out of leveraging that work as it materializes.

-adam

---

From: John Bradley <[email-masked]>
Date: Thu, 15 May 2014 23:00:45 +0200

The key for pop via the browser is different than the one between the client and the RS.   The key representation is likely to be the same but presentment will likely be different. 

This WG is focusing on OAuth tokens and assertion flows. 

Getting a id_token with HoK for use in an assertion flow may be done in JOSE or Connect. 

Nothing is impossible if the WG rechargers and wants to do it as part of JWT. 

Sent from my iPhone

> On May 15, 2014, at 9:31 PM, Lewis Adam-CAL022 <[email-masked]> wrote:
> 
> Hi,
>  
> Does the WG plan to include OIDC id_tokens within the scope of the HOTK/POP work?  I’ve scanned through all of the existing HOTK/POP drafts and none make any reference to id_tokens.  Is this effort going to be scoped strictly to access tokens? 
>  
> I am at a cross road right now where I’m considering using id_tokens in lieu of access_tokens within our API calls (as we were never using the access tokens for authorization anyway, but rather had profiled the AT to look identical to an id_token for authentication, and now that OIDC is complete … you get the idea), … BUT … we want HOTK/POP badly, and I don’t want to design ourselves out of leveraging that work as it materializes.
>  
>  
> -adam
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth