I support keeping those two in a single document.
They actually belong to a same class of problem: the problem of accepting
an input from an untrusted / un-protected source, i.e., the authorization
response.
When this vulnerability is applied to the 'state', it opens up the chance
of authorization
Hi,
I think it is a reasonable simplification to mandate that PoP key and
(D)TLS Mode matches i.e. if the PoP keys is symmetric the (D)TLS mode would
be PSK, if the PoP key is asymmetric (D)TLS mode would be Raw Public key.
But I think there is some compelling properties of having a symmetric PoP
Ludwig Seitz wrote:
> On 02/04/2016 03:31 PM, Michael Richardson wrote:
>>
>> Ludwig Seitz wrote: > Assuming we are using (D)TLS to
>> secure the connection between C and RS, > assuming further that we are
>> using proof-of-possession tokens [2], > i.e. tokens linked to a key
There is a more general problem in PaaS deployment about how RA and AS
infrastructure discover and coordinate with each other. For the most part this
hasn't been necessary since usually the AS and RS are controlled by the same
admins. But in PaaS/IaaS the requirements vary widely.
How does an
The RS is going to have to advertise what presentment mechanisms it supports.
We don’t have that yet. I suspect that it might be part of OAuth Discovery.
Currently that mostly cover AS discovery, but for the RS I could see doing a
head on the resource and getting back a link to a JSON documen
Yes this is an example of how you could do it inside the existing specs.
I guess you could look at it as token transformation for software statements.
This and signed state were created based on developer feedback that we tell
them that they need to do something or that they can do something i
Michael,
thank you for answering, this is getting very interesting.
Comments inline.
/Ludwig
On 02/05/2016 04:26 PM, Michael Richardson wrote:
First, let me say that I confused RS and RO/AS in my mind when reading before.
Starting again, I think that any PSK for authentication between C<->R