Actually, I view this in a much simpler way. In today's environment
there is a tight coupling between AS and RS. Each deployment has to
develop it's own mechanism for dealing with understanding tokens (even
if the AS and RS are in the same domain).
The introspection spec solve probably 80+ percent of those tight
coupling use cases.
As an RS, I do not want to have to write special code for every AS to
understand their unique token or mechanism for validating tokens and I'm
sure that every AS does not want to implement our specific token. In
both of these cases there is a tight coupling required.
As for the privacy issues, the introspection endpoint is an OAuth2
protected API and can enforce the presentation of an authorization token
(RFC 6750) before responding with the token data. This allows for the
return of pseudonymous identifiers and other privacy protecting mechanisms.
Thanks,
George
// Line feeds added for formatting purposes only :)
{
"bit_of_a_rant" : "Since the introspection spec is not mandatory to
implement, I don't see why there is such concern
over
it. If an AS doesn't want to implement the endpoint,
they don't need to. However, for those who do
(and there
is a good number in this community) it solves a
real problem."
}
On 7/29/14, 7:44 PM, Phil Hunt wrote:
Thanks everyone for the comments.
It sounds like we have multiple dimensions to introspection features
and requirements:
* there are UMA cases,
* corporate third-party AS-RS relationships (e.g. the RS chooses a
third-party AS),
* multi-vendor cases,
* tooling/library cases,
There’s also federation cases. Federated authorization seems like a
different problem than federated authentication from a trust perspective.
Another dimension to this is methodology:
1. Lookup by token / token id / reference
2. Query by token / token id / reference
3. Passing standardized information in a standardized token format or
token URI.
There may be some complex privacy issues involved as well. For
example, in many cases, the desire is to allow authz information
*only* the actual content owner / delegator may be intentionally
pseudonymous.
_I would support first developing a use case document to figure out if
there is an appropriate pattern that can satisfy (and simplify) a
majority of cases._
Phil
@independentid
www.independentid.com <http://www.independentid.com>
phil.h...@oracle.com <mailto:phil.h...@oracle.com>
On Jul 29, 2014, at 3:24 PM, George Fletcher <gffle...@aol.com
<mailto:gffle...@aol.com>> wrote:
We also have a use case where the AS is provided by a partner and the
RS is provided by AOL. Being able to have a standardized way of
validating and getting data about the token from the AS would make
our implementation much simpler as we can use the same mechanism for
all Authorization Servers and not have to implement one off solutions
for each AS.
Thanks,
George
On 7/28/14, 8:11 PM, Phil Hunt wrote:
Could we have some discussion on the interop cases?
Is it driven by scenarios where AS and resource are separate
domains? Or may this be only of interest to specific protocols like UMA?
From a technique principle, the draft is important and sound. I am
just not there yet on the reasons for an interoperable standard.
Phil
On Jul 28, 2014, at 17:00, Thomas Broyer <t.bro...@gmail.com
<mailto:t.bro...@gmail.com>> wrote:
Yes. This spec is of special interest to the platform we're
building for http://www.oasis-eu.org/
On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig
<hannes.tschofe...@gmx.net <mailto:hannes.tschofe...@gmx.net>> wrote:
Hi all,
during the IETF #90 OAuth WG meeting, there was strong consensus in
adopting the "OAuth Token Introspection"
(draft-richer-oauth-introspection-06.txt) specification as an
OAuth WG
work item.
We would now like to verify the outcome of this call for
adoption on the
OAuth WG mailing list. Here is the link to the document:
http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/
If you did not hum at the IETF 90 OAuth WG meeting, and have an
opinion
as to the suitability of adopting this document as a WG work item,
please send mail to the OAuth WG list indicating your opinion
(Yes/No).
The confirmation call for adoption will last until August 10,
2014. If
you have issues/edits/comments on the document, please send these
comments along to the list in your response to this Call for
Adoption.
Ciao
Hannes & Derek
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
--
Thomas Broyer
/tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto: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
