On Fri, Feb 26, 2021 at 8:10 AM Justin Richer wrote:
> Right, it’s possible to patch OAuth to do this, but the whole
> “registration equals trust” mindset is baked into OAuth at a really core
> level. That’s one of the main reasons there’s been hesitance at deploying
> dynamic registration. It’s
The OAuth work has successfully built a perfectly reasonable syntax and
protocol for exchanging identity and attribute assertions, and that's
fine. What it hasn't done is opened up the world of Identity Provision,
but that's not a technical problem.
OAuth flowed out of OpenID back in the day. Th
;t know what clients are using the play API to get 3rd party tokens.
>
> Perhaps Tim Bray can comment on scale of use if not specific clients.
>
> John B.
>
> On Mar 27, 2014, at 3:36 PM, Lewis Adam-CAL022 <
> adam.le...@motorolasolutions.com> wrote:
>
> I get the i
On Fri, Oct 25, 2013 at 1:41 PM, Phil Hunt wrote:
> Finally, I'm not sure who might be able to lead this (Tim?), but there was
> some interesting views expressed by Google staffers at this weeks IIW in
> Mountain View that seem to indicate that the need for client credentials in
> mobile apps may
is registration feature entirely.
>
>
>
> But understanding it might be useful in some contexts, I’m OK keeping it,
> provided we be clear that the semantics of “registered to use” are
> service-specific.
>
>
>
>
ding it might be useful in some contexts, I’m OK keeping it,
> provided we be clear that the semantics of “registered to use” are
> service-specific.
>
> ** **
>
> -- Mike
>
> ** **
>
> *From:* Tim Bray
> -- Mike
>
> ** **
>
> *From:* Justin Richer [mailto:jric...@mitre.org]
> *Sent:* Monday, April 15, 2013 12:29 PM
>
> *To:* Mike Jones
> *Cc:* Tim Bray; oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Registration: Scope Values**
*Justin Richer
> *Sent:* Monday, April 15, 2013 8:05 AM
> *To:* Tim Bray; oauth@ietf.org
>
> *Subject:* Re: [OAUTH-WG] Registration: Scope Values****
>
> ** **
>
> On 04/15/2013 10:52 AM, Tim Bray wrote:
>
>
>
> I’d use the existing wording; it’s per
he AS and PR (or a higher-level protocol
> like UMA).
>
> -- Justin
>
>
> On 04/15/2013 10:13 AM, Tim Bray wrote:
>
> This, as written, has zero interoperability. I think this feature can
> really only be made useful in the case where scopes are fixed strings.
>
> -T
This, as written, has zero interoperability. I think this feature can
really only be made useful in the case where scopes are fixed strings.
-T
On Apr 15, 2013 6:54 AM, "Justin Richer" wrote:
> You are correct that the idea behind the "scope" parameter at
> registration is a constraint on auth
Speaking for myself, I have considerable concern about Turing-complete
programming languages starting to emerge inside scope strings, which I
think is probably a symptom of bad engineering. I really like the idea of
specifying the scopes you’re going to ask for at registration time, and if
that al
oing to change,
> it should be soon.
>
> ** **
>
> -- Mike
>
> ** **
>
> ** **
>
> *From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf
> Of *Nat Sakimura
> *Sent:* Wednesday
In OAuth, we have redirect_uri not redirect_url; should this be
registration_access_uri for consistency? -T
On Wed, Feb 20, 2013 at 8:23 AM, John Bradley wrote:
> I think registration_access_url is OK.I haven't heard any better names
> yet.
>
> John B.
>
> On 2013-02-20, at 1:04 PM, Mike Jon
Not deeply acquainted with the Flickr scenario, but it occurs to me to ask:
If OAuth 1.0 is working well for them, why don’t they just keep using it?
I.e. if there’s already a good solution in place for people who require
secure authn/authz over insecure channels, why would we go the extra work
of
A DELETE is an http request that asks the server to delete something. We
probably would want to avoid writing a requirement into the standard that
the server has to comply. So you get back a 204 if it worked, a 404 if
there is no such registration, a 403 if there is but the server declines to
del
On Tue, Feb 12, 2013 at 11:44 AM, John Bradley wrote:
> Nat and I hashed out the pro's and cons of JSON requests.
>
> If we POST or PUT a JSON object we need to be specific as there rare
> several ways to do it that may work better or worse depending on the
> receiver.
> This needs to be looked o
?! /foo and /foo/bar are obviously distinct endpoints.
On Feb 12, 2013 3:25 AM, "Sergey Beryozkin" wrote:
> Hi Mike,
> On 12/02/13 01:26, Mike Jones wrote:
>
>> At most, there should be two endpoints - creation and management - for a
>> client, but the protocol should be structured such that they
OIDC seems about the most plausible candidate for a “good general solution”
that I’m aware of. -T
On Tue, Feb 5, 2013 at 1:22 PM, William Mills wrote:
> There are some specific design mis-matches for OAuth as an authentication
> protocol, it's not what it's designed for and there are some probl
>From the point of view of developer experience, meh, the degree of
difficulty of generating/parsing JSON & form/url is about the same.
JSON has the advantage that it forces you to use UTF-8, and is more
pleasant to debug when things get weird.
For my money, anything that forces anyone to use UTF
As I read back through this one I’m not getting why you need a new refresh
token. What am I missing? -T
On Mon, Nov 26, 2012 at 6:27 PM, Brian Eaton wrote:
> On Fri, Nov 23, 2012 at 4:43 AM, Bob Gregory wrote:
>
>> We've had OAuth2 running successfully for a while now, but we're finding
>> th
Quick question: Why is it “association request”, not “registration
request”? Nearly everywhere the term “association” appears, it seems like
you could insert “registration” and achieve better clarity. -T
On Mon, Nov 5, 2012 at 2:20 PM, Richer, Justin P. wrote:
> This draft combines the best-usa
That might have happened had there been some free high-quality ASN.1
software, instead of slow buggy parsers that cost $50K to license.
It’s always seemed to me that one reason XML took off so fast is that
there were fast robust open-source parsers in C and Java before the
spec was even finalized.
There's a disconnect here. Mnot and I (at least) have argued that
there are very specific problems and costs associated with going
multi-format. I’ve heard lots of people say "Well, I support
multi-format” but I haven’t heard any specific responses explaining
why those costs and problems aren’t re
that would be what was done with
> OpenID Connect ;-)
>
> Seriously... is there no sense of maintaining backward compatibility and
> rigidly defining protocols for the long-term?
>
> Paul
>
>> -Original Message-
>> From: Tim Bray [mailto:tb...@text
No. Supporting two different on-the-wire data formats is actively
harmful. Here are two pieces which explain why:
- mnot, this month: http://www.mnot.net/blog/2012/04/13/json_or_xml_just_decide
- Me, back in 2009
Pick one. -T
On Thu, Apr 19, 2012 at 8:15 PM, Paul E. Jones wrote:
> Mike,
>
>> T
What is the deployment status of these two specs? Is either deployed
much at all? -T
On Fri, Apr 13, 2012 at 10:45 AM, Murray S. Kucherawy
wrote:
>> -Original Message-
>> From: apps-discuss-boun...@ietf.org [mailto:apps-discuss-boun...@ietf.org]
>> On Behalf Of Stephen Farrell
>> Sent
26 matches
Mail list logo
