BrentSchmaltz
BrentSchmaltz
@fragilethoughts I agree we need async, particularly with delegation to validation services, such as KeyVault and Google. Not only do we need ValidateTokenAsync, we need async on our Crypto such...
@mcthuesen We haven't moved forward much on this, but it is important for a number of reasons. We are not sure if this fits into our 5.x release or will...
@LeroyK at the earliest in the 1st qtr of 2020 for a full stack. However if Async Delegates were available would that satisfy a pent up need? That may be...
@daniel-munch-cko we are working on shipping 6.x where we have a number of internal fixes being validated. Once that is out, we will address this as a lot of interest...
@cyberhck @stebet @daniel-munch-cko yes we hear you. We have some internal work to do with our 6.x branch (our dev is ahead of dev5x). We do not want to backport...
@bugproof fair enough. When opened the win was seen as a programming convenience, in a large number of cases, as almost all crypto operations were inproc and synchronous. That has...
@Mordahlhuilhulh not yet ...
@dorinung yes, there are additional claim names. Not sure when we will add them all.
@leastprivilege this is a case I don't think we have considered. EC keys are supported, but we have never tested this scenario. It seems reasonable, are you exploring a new...
@jaanclaeys @scottbrady91 @leastprivilege I agree with you folks, we should make this work. ECD is preferred by many people. We can't fit this into our SignedHttpRequest effort (our next release),...