[At-Risk] Implementations of PoPSecurityScheme needed

[mmccool]

The PoPSecurityScheme is currently at risk.

• 2 implementations of all features are needed

[mkovatsc]

I am removing the "by PR transition" label, as these at-risk features will be dropped given the implementation report.

[sebastiankb]

@mmccool If I'm correct there is no PoPSecurityScheme implementation yet, right?

Shall we still wait for PR transition?

[mmccool]

Updated for CR2... this is still at risk, with 0 implementations. Actually, the results are a little odd, since there is 1 manual assertion for PoP default values but no TDs that use it in the test cases.

[mmccool]

PoP however is basically an experimental security scheme so it can be removed without much practical impact in this round. We probably do want to try again in the next round.

A little off-topic, but Cert and Public probably should be removed, as they are not very well defined.

[sebastiankb]

@mmccool I think there are no 2 implementations, right? we should start to remove the parts from the TD spec

[sebastiankb]

PoPSecurityScheme is removed from v1.0. will be addressed for v.1.1

[mmccool]

We did not include PoP in TD 1.1. However, there is some activity in IETF to extend the authentication protocols for OAuth2 to include a means for demonstrating possession of bearer tokens (see below) rather than introducing a new kind of token. We can push it off to TD 2.0 - we have to wait to see if the IETF comes up with something. See below:

https://www.ietf.org/id/draft-ietf-oauth-dpop-09.html#name-compatibility-with-the-bear

[egekorkan]

I have added the use case potential but I would prefer if someone creates a use case mentioning pop security scheme instead of the TD TF doing that. We had put it before but there was no implementations of it so there was no need raised by anyone to include it.