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 protected]> 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 protected] > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
