Thanks Derek, I will take a look at this.
Phil @independentid www.independentid.com phil.h...@oracle.com > On Jul 10, 2015, at 1:48 PM, Derek Atkins <de...@ihtfp.com> wrote: > > Hi, > > In performing my shephard review of draft-ietf-oauth-pop-architecture I > found one issue that was bugging me: you talk about target naming "too > late" in the draft. I.e., as I was reading through section 3.1 about > token reuse I think it doesn't have enough detail about how you would > prevent server A asking the client for a token for a resource of server > B, and then server A acting as the client for server B? I.e., how do > you prevent server A acting as a MITM between the client and server B? > (This is sort of the same question that resulted in TLS channel > bindings). > > I know this target (scope) protection exists, and it's even discussed a > bit later in the document but it's not even mentioned as a possible > threat in 3.1, which seems like a glaring ommission. > > I'll create a more formal shephard review but I'd suggest some > additional text to at least mention this threat in 3.1; you can provide > a pointer to the protections then, too. > > -derek > -- > Derek Atkins 617-623-3745 > de...@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
