[OAUTH-WG] Inaccuracy in last point in JWSREQ presentation about registering request_object_signing_alg

The last bullet of the last slide of https://www.ietf.org/proceedings/94/slides/slides-94-oauth-5.pdf says: Section 7 - False statement: ● The request_object_signing_alg OAuth Dynamic Client Registration Metadata is pending registration by OpenID Connect Dynamic Registration specification

[OAUTH-WG] Queue for oauth Remote Attendees

If you are planning to participate in the oauth session here at IETF 94 today — either locally in Yokohama or as a remote participant — we want to make sure that you are aware that the IETF is providing remote participants with a fairly new way to ask questions or make comments. In addition to u

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

Good to know. So the AS needs to expose a public key for the TPM to use for encryption. I am guessing you are not using a encrypted JWK for that. What is the format the TPM produces the wrapped key in? John B. > On Nov 5, 2015, at 1:55 PM, Anthony Nadalin wrote: > > I can say on all windo

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

I can say on all windows based devices (pc, xbox, phone, etc) with only TPM 1.1 this will be the approach so it will be commonly used -Original Message- From: John Bradley [mailto:ve7...@ve7jtb.com] Sent: Wednesday, November 4, 2015 8:52 PM To: Anthony Nadalin Cc: Justin Richer ; Sub

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

Our use case involves mostly hardware (TPM 1.2) based key generation, where the hardware (TPM 1.1) is slow we will use secure software execution environment, our use case is always client side generated keys -Original Message- From: Justin Richer [mailto:jric...@mit.edu] Sent: Wednesday

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

OK, no good reason unless the client is using a HSM that can do HMAC and can export a symmetric key wrapped in a asymmetric key provided by the AS. We don’t currently cover that use case of sending a wrapped symmetric key to the AS in POP key distribution. I don’t know how common that is goin

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

That’s only if you’re using good hardware to produce a key. We can’t assume that’s the only kind of client that will exist, and software generation is likely to be much more common for a while yet. Perhaps what we really need is strong guidance on when to use which approach. “If you client has

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

Not sure why you think its weaker as it would be a wrapped key that the hardware produces -Original Message- From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley Sent: Wednesday, November 4, 2015 8:43 PM To: Justin Richer Cc: Subject: Re: [OAUTH-WG] Proof-of-Possessio

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

In the asymmetric case the use of a HSM or secure element is the argument for the client selecting the public key. In those cases the client is doing the key gen in hardware so one hopes it is OK. In the symetric case the client generating the key is weaker (as in I can’t think of any really

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

I’d argue that it’s best practice, and in line with other parts of OAuth, if we assume the server generates it in the normal case (issuer -> presenter). Client generated token keys should be an exception, especially in the asymmetric case. — Justin > On Nov 5, 2015, at 1:32 PM, John Bradley w

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

Agreed the only real difference is the quality of the key. If the server generates it, then it knows that the client is not using the fixed hex value of DEADBEEF for everything. John B. > On Nov 5, 2015, at 9:25 AM, Hannes Tschofenig > wrote: > > I agree that the effect is the same. From a s

Re: [OAUTH-WG] OAuth Device Flow

Google has additional documentation here: https://developers.google.com/identity/protocols/OAuth2ForDevices The implementation mostly follows the original draft, but there are a few differences. Also we've learnt a lot about the security and usability implications of this flow along the way, which

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

Good point. I'll republish in the next day or so adding that to the security considerations. -- Mike -Original Message- From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net] Sent: Thursday, November 05, 2015 9:26 AM To: Mike Jones; Brian Campbell Cc

[OAUTH-WG] OAuth Device Flow

FYI: A couple of us got together and re-published an old, expired draft about the OAuth Device Flow. Here is the document: https://tools.ietf.org/html/draft-denniss-oauth-device-flow-00 For the -00 version we tired to keep it inline with what has been available with draft-recordon-oauth-v2-device

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

I agree that the effect is the same. From a security point of view there is only an impact if one of the two parties is in a better position to generate random numbers, which is the basis for generating a high entropy symmetric key. On 11/04/2015 11:51 PM, Mike Jones wrote: > Thanks for the detail

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

Thanks for the detailed read, Brian. You’re right that in the symmetric case, either the issuer or the presenter can create the symmetric PoP key and share it with the other party, since the effect is equivalent. I suspect that both the key distribution draft and this draft should be updated w

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

+1 for the diagrams making the document more understandable. One little nit/question, step 1 in both Symmetric and Asymmetric keys shows the Presenter sending the key to the Issuer. It's possible, however, for the key to be sent the other way. Presenter sending it to the Issuer is probably preferr

Re: [OAUTH-WG] Sharing a client_id: is it good or bad ?

For a native app you can have one clientID and no secret (same as having one secret for all of them) or you can use dynamic client registration to give each one a separate client_id and secret. The middle ground is to use PKCE and no client secret. The client generates a pkce challenge in the

[OAUTH-WG] Re

Reply http://about.me/ronaldo_comaling ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

Thank you Mike. The diagrams look good to me. Kind Regards Kepeng 发件人: Mike Jones 日期: Thursday, 5 November, 2015 12:32 am 至: "oauth@ietf.org" 抄送: Li Kepeng 主题: Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment Proof-of-Possession Key Semantics for JWTs dr

Re: [OAUTH-WG] Sharing a client_id: is it good or bad ?

> And what about multiple confidential clients being set up with the same > id/secret. Bad idea. For security when you see one confidential client doing bad things you will need to revoke it individually. If multiple confidential clients have the same client secrets, thats no longer possible.

Re: [OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

Thanks for suggesting the diagrams, Kepeng. They make the document more understandable. -- Mike From: Kepeng Li Sent: ‎11/‎5/‎2015 12:57 AM To: Mike Jones; oauth@ietf.org

[OAUTH-WG] Sharing a client_id: is it good or bad ?

Hi All I'm having a discussion with my colleagues on the pros and cons of sharing a client_id. For example, say we have N number of public mobile applications (the same application package, an application instance on an individual phone), and one approach is for each of these applications to

[OAUTH-WG] Proof-of-Possession Key Semantics for JWTs spec addressing final shepherd comment

Proof-of-Possession Key Semantics for JWTs draft -06 addresses the remaining document shepherd comment - adding use case diagrams to the introduction. The updated specification is available at: *http://tools.ietf.org/html/draft-ietf-oauth-proof-of-possession-06 An HTML formatted version

[OAUTH-WG] I-D Action: draft-ietf-oauth-proof-of-possession-06.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) Authors : Michael B. Jon