inline below
On Tue, Nov 6, 2018 at 12:53 PM Evan Gilman wrote:
> There are some extra things we could do if we attached type-specific
> semantics to the matching (e.g. DNS wildcarding etc), however I think
> that continuing to use the values as opaque identifiers would get us
> most of what we
Sure, I think they could be treated as different different
client_auth_methods. But there is a lot more commonality than differences
to the point where I think it makes sense to keep it all in a single
document and under a single client auth method with just the variation on
which name is being use
Hi Aaron,
Thanks for putting this document together, I think this kind of guidance is
invaluable.
It may be worth slightly rewording 7.2 as it may encourage a growing
misconception that all native apps must be public clients. With many devices
now having embedded HSMs, we’ve seen increasing in
It's an interesting topic. I think there is a definitely a set of
options and considerations for this. Namely operational. For example,
hugely popular mobile apps (multi-million downloads across different
OS's) using dynamic reg with per-instance private creds requires the AS
to be able to store
> On Nov 7, 2018, at 9:08 AM, Simon Moffatt wrote:
>
> It's an interesting topic. I think there is a definitely a set of options
> and considerations for this. Namely operational. For example, hugely
> popular mobile apps (multi-million downloads across different OS's) using
> dynamic reg w
Have we considered replacing the device_code logic with PKCE now that
PKCE exists? At the time we started this spec I'm not sure PKCE was
around, but now that it exists and is required (practically speaking)
for mobile apps, should we look at using it instead of device_code to
protect this flow
Related to this discussion of AS discovery... what is the value of using
the Link response header over just returning the variables in the
WWW-Authenticate header? Could we not use...
WWW-Authenticate: OAuth realm="example_realm", scope="example_scope",
error="invalid_token", rs_uri="https://a
I’m seeing broader need for discovery of OAuth infrastructure for APIs in
general now that APIs are being deployed by many parties:
* based on a standard (e.g. SCIM, IMAP, SMTP)
* Implemented in open source and deployed by many (e.g. K8S and its various
components).
* Services like streaming (Kak
