Hi Ben,

> I've forgotten the details of those two documents, but in the general case, 
> if there's a WG document that is no longer actively being worked on (or is 
> now believed to be a bad idea), the chairs can pretty easily get a new rev 
> posted that has a "tombstone" notice, like "this document is no longer being 
> worked on" or similar, which may help clarify the situation to external 
> parties without much investment on time or tooling.

When we started the work on the PoP tokens we were ahead of the OAuth 
deployment because many developers didn't see the need to switch from the 
bearer tokens to the proof-of-possession tokens. Hence, the work progressed 
very slowly.

Now, the situation has changed with OAuth being used in use cases where there 
are higher security concerns, for example in the financial sector.

There are, however, also technical challenges with the PoP token approach and 
we ran into one of them with the HTTP signing and also deployment challenges 
(see token binding). I believe many people want such a PoP solution but there 
are just cases where it does not work. For HTTP signing we have at least two 
solutions in the IETF right now, namely  
https://tools.ietf.org/html/draft-ietf-oauth-signed-http-request-03 and 
https://tools.ietf.org/html/draft-cavage-http-signatures-11

DPoP does not address the issue of how the request from the Client to the RS is 
actually protected. It only hints to it. If you want to get this to work you 
have to use one of the above documents or come up with yet another method.

Additionally, DPoP overlaps an already existing working group item, which we 
had planned to sent to the IESG soon: 
https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-07
One of the differences between DPoP and PoP key distribution is the question 
whether the client always needs to demonstrate possession of the private to the 
AS. As you remember I took the action item to work on a formal analysis, which 
I posted to the list.

Why the extra DPoP functionality has not been incorporated into the already 
chartered working group item is not entirely clear to me.

Ciao
Hannes
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to