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
