Am 28.07.2010 um 01:40 schrieb Brian Eaton bea...@google.com:
On Tue, Jul 27, 2010 at 11:56 AM, Brian Campbell
bcampb...@pingidentity.com wrote:
There seem to be two potential arguments against it - the burden of
tracking the state and the potential that it's unnecessarily
restrictive. I
thanks for sharing your thoughts.
Differentiating resource servers by using different end-user
authorization endpoint URLs is an option. I dont't know how this will
work in conjunction with discovery, especially since this
differentiation might by required on other endpoints, too. For
+1 on MAY; (+0.3 on SHOULD).
Igor
Torsten Lodderstedt wrote:
Am 28.07.2010 um 01:40 schrieb Brian Eaton bea...@google.com:
On Tue, Jul 27, 2010 at 11:56 AM, Brian Campbell
bcampb...@pingidentity.com wrote:
There seem to be two potential arguments against it - the burden of
tracking
MAY it is. Thanks
On Jul 28, 2010 4:06 AM, Igor Faynberg igor.faynb...@alcatel-lucent.com
wrote:
+1 on MAY; (+0.3 on SHOULD).
Igor
Torsten Lodderstedt wrote:
Am 28.07.2010 um 01:40 schrieb Brian Eaton bea...@google.com:
...
___
OAuth mailing
On Tue, Jul 27, 2010 at 4:31 PM, Nat Sakimura sakim...@gmail.com wrote:
Hi.
Currently, the discovery document would have something like:
{
verification_keys: {
key1:RSA.ALqcwR...,
key2:X509.certificate
}
}
It defines RSA and X509. Could we
Folks interested in protected feeds may be interested in UMA's solution, which
proposes mechanisms to demand claims from the requesting side based on
user-specified policyon the authorizing server side. An example of
UMA-protected resources that require agreement to terms can be seen in the
Belatedly... Sorry if I sound like a broken record on this, but: Most of UMA's
use involve letting a user introduce their various hosts (UMA-flavored resource
servers) to their single chosen authorization manager (UMA-flavored
authorization server), by treating the former as a dynamically
