Hi Mike, Nat, John,
thanks for starting this work.
It seems you assume the AS can always be discoverd using the user id of
the resource owner. I think the underlying assumption is resource
servers accept access token of different (any?) user specific AS (and
OP)? From my perspective, RSs nowadays typically trust _the_ AS of their
security domain/ecosystem and all resource owners need to have an user
account with this particular AS. So I would assume the process to start
at the RS. We potentially need to cover for both cases.
What do you think?
best regards,
Torsten.
Am 26.11.2015 um 00:37 schrieb Mike Jones:
I’m pleased to announce that Nat Sakimura, John Bradley, and I have
created an OAuth 2.0 Discovery specification. This fills a hole in
the current OAuth specification set that is necessary to achieve
interoperability. Indeed, the Interoperability section of OAuth 2.0
<https://tools.ietf.org/html/rfc6749#section-1.8>states:
In addition, this specification leaves a few required components
partially or fully undefined (e.g., client registration, authorization
server capabilities, endpoint discovery). Without these components,
clients must be manually and specifically configured against a
specific authorization server and resource server in order to
interoperate.
This framework was designed with the clear expectation that future
work will define prescriptive profiles and extensions necessary to
achieve full web-scale interoperability.
This specification enables discovery of both endpoint locations and
authorization server capabilities.
This specification is based upon the already widely deployed OpenID
Connect Discovery 1.0
<http://openid.net/specs/openid-connect-discovery-1_0.html>
specification and is compatible with it, by design. The OAuth
Discovery spec removes the portions of OpenID Connect Discovery that
are OpenID specific and adds metadata values for Revocation and
Introspection endpoints. It also maps OpenID concepts, such as OpenID
Provider, Relying Party, End-User, and Issuer to their OAuth
underpinnings, respectively Authorization Server, Client, Resource
Owner, and the newly introduced Configuration Information Location.
Some identifiers with names that appear to be OpenID specific were
retained for compatibility purposes; despite the reuse of these
identifiers that appear to be OpenID specific, their usage in this
specification is actually referring to general OAuth 2.0 features that
are not specific to OpenID Connect.
The specification is available at:
·http://tools.ietf.org/html/draft-jones-oauth-discovery-00
An HTML-formatted version is also available at:
·http://self-issued.info/docs/draft-jones-oauth-discovery-00.html
-- Mike
P.S. This note was also posted at http://self-issued.info/?p=1496
<http://self-issued.info/?p=1496> and as @selfissued
<https://twitter.com/selfissued>.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
