I think it is more likely that the flow for the user will be that they know an
RS and the RS provides some reference to the AS. The RS might well consume a
generic lookup flow though. We do need the "updated webfinger thing" for users
as a generic though.
The WF type thing for a generic user lookup in a domain might be used for
discovering the SMTP/IMAP/webmail entrypoints for a user along with the AS and
that's another possible useful thing. User specific rather than apparently
server/service specific.
On Sunday, December 13, 2015 12:59 PM, Torsten Lodderstedt
<tors...@lodderstedt.net> wrote:
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:
#yiv5368577927 #yiv5368577927 -- _filtered #yiv5368577927
{font-family:Wingdings;panose-1:5 0 0 0 0 0 0 0 0 0;} _filtered #yiv5368577927
{panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv5368577927
{font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #yiv5368577927
{panose-1:2 11 5 2 4 2 4 2 2 3;}#yiv5368577927 #yiv5368577927
p.yiv5368577927MsoNormal, #yiv5368577927 li.yiv5368577927MsoNormal,
#yiv5368577927 div.yiv5368577927MsoNormal
{margin:0in;margin-bottom:.0001pt;font-size:11.0pt;}#yiv5368577927 a:link,
#yiv5368577927 span.yiv5368577927MsoHyperlink
{color:#0563C1;text-decoration:underline;}#yiv5368577927 a:visited,
#yiv5368577927 span.yiv5368577927MsoHyperlinkFollowed
{color:#954F72;text-decoration:underline;}#yiv5368577927 pre
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv5368577927
p.yiv5368577927MsoListParagraph, #yiv5368577927
li.yiv5368577927MsoListParagraph, #yiv5368577927
div.yiv5368577927MsoListParagraph
{margin-top:0in;margin-right:0in;margin-bottom:0in;margin-left:.5in;margin-bottom:.0001pt;font-size:11.0pt;}#yiv5368577927
span.yiv5368577927EmailStyle17 {color:windowtext;}#yiv5368577927
span.yiv5368577927HTMLPreformattedChar {}#yiv5368577927 span.yiv5368577927grey
{}#yiv5368577927 .yiv5368577927MsoChpDefault {} _filtered #yiv5368577927
{margin:1.0in 1.0in 1.0in 1.0in;}#yiv5368577927 div.yiv5368577927WordSection1
{}#yiv5368577927 _filtered #yiv5368577927 {} _filtered #yiv5368577927
{font-family:Symbol;} _filtered #yiv5368577927 {} _filtered #yiv5368577927
{font-family:Wingdings;} _filtered #yiv5368577927 {font-family:Symbol;}
_filtered #yiv5368577927 {} _filtered #yiv5368577927 {font-family:Wingdings;}
_filtered #yiv5368577927 {font-family:Symbol;} _filtered #yiv5368577927 {}
_filtered #yiv5368577927 {font-family:Wingdings;}#yiv5368577927 ol
{margin-bottom:0in;}#yiv5368577927 ul {margin-bottom:0in;}#yiv5368577927 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 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 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 and as @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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
