Dikirim dari ponsel cerdas BlackBerry 10 saya dengan jaringan Telkomsel.
Dari: oauth-requ...@ietf.org
Terkirim: Rabu, 30 Juli 2014 03.42
Ke: oauth@ietf.org
Balas Ke: oauth@ietf.org
Perihal: OAuth Digest, Vol 69, Issue 134
Send OAuth mailing list submissions to
oauth@ietf.org
To subscribe or unsubscribe via the World Wide Web, visit
https://www.ietf.org/mailman/listinfo/oauth
or, via email, send a message with subject or body 'help' to
oauth-requ...@ietf.org
You can reach the person managing the list at
oauth-ow...@ietf.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of OAuth digest..."
Today's Topics:
1. Re: Confirmation: Call for Adoption of "OAuth Token
Introspection" as an OAuth Working Group Item (Phil Hunt)
----------------------------------------------------------------------
Message: 1
Date: Tue, 29 Jul 2014 13:41:16 -0700
From: Phil Hunt <phil.h...@oracle.com>
To: Justin Richer <jric...@mitre.org>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth
Token Introspection" as an OAuth Working Group Item
Message-ID: <620af4ca-b7f7-487e-a833-3483d2b41...@oracle.com>
Content-Type: text/plain; charset="utf-8"
Making everything optional achieves no benefits, you just end up with a complex
set of options and no inter op.
We had the same issue with dyn reg.
I prefer to first get agreement on use case.
What are the questions a caller can ask and what form of responses are
available.
Should this be limited to authz info or is this a back door for user data and
wbfinger data?
I would prefer to have agreement on use cases before picking a solution right
now.
Phil
> On Jul 29, 2014, at 11:13, Justin Richer <jric...@mitre.org> wrote:
>
> Agreed on this point -- which is why the only MTI bit in the individual draft
> is "active", which is whether or not the token was any good to begin with.
> There are a set of claims with defined semantics but all are optional, and
> the list is extensible. I think in practice we'll see people settle on a set
> of common ones.
>
> -- Justin
>
>> On 07/29/2014 02:11 PM, Bill Mills wrote:
>> This is exactly the same problem space as webfinger, you want to know
>> something about a user and there's a useful set of information you might
>> reasonably query, but in the end the server may have it's own schema of data
>> it returns. There won't be a single schema that fits all use cases, Any
>> given RS/AS ecosystem may decide they have custom stuff and omit other
>> stuff. I think the more rigid the MTI schema gets the harder the battle in
>> this case.
>>
>>
>> On Tuesday, July 29, 2014 2:56 AM, Paul Madsen <paul.mad...@gmail.com> wrote:
>>
>>
>> Standardized Introspection will be valuable in NAPPS, where the AS and RS
>> may be in different policy domains.
>>
>> Even for single policy domains, there are enterprise scenarios where the RS
>> is from a different vendor than the AS, such as when an API gateway
>> validates tokens issued by an 'IdP' . We've necessarily defined our own
>> introspection endpoint and our gateway partners have implemented it, (at the
>> instruction of the customer in question). But of course it's proprietary to
>> us.
>>
>> Paul
>>
>> On Jul 28, 2014, at 8:59 PM, Phil Hunt <phil.h...@oracle.com> wrote:
>>
>>> That doesn?t explain the need for inter-operability. What you?ve described
>>> is what will be common practice.
>>>
>>> It?s a great open source technique, but that?s not a standard.
>>>
>>> JWT is much different. JWT is a foundational specification that describes
>>> the construction and parsing of JSON based tokens. There is inter-op with
>>> token formats that build on top and there is inter-op between every
>>> communicating party.
>>>
>>> In OAuth, a site may never implement token introspection nor may it do it
>>> the way you describe. Why would that be a problem? Why should the group
>>> spend time on something where there may be no inter-op need.
>>>
>>> Now that said, if you are in the UMA community. Inter-op is quite
>>> foundational. It is very very important. But then maybe the spec should be
>>> defined within UMA?
>>>
>>> Phil
>>>
>>> @independentid
>>> www.independentid.com
>>> phil.h...@oracle.com
>>>
>>>
>>>
>>>> On Jul 28, 2014, at 5:39 PM, Justin Richer <jric...@mit.edu>
>>>> wrote:
>>>>
>>>> It's analogous to JWT in many ways: when you've got the AS and the RS
>>>> separated somehow (different box, different domain, even different
>>>> software vendor) and you need to communicate a set of information about
>>>> the approval delegation from the AS (who has the context to know about it)
>>>> through to the RS (who needs to know about it to make the authorization
>>>> call). JWT gives us an interoperable way to do this by passing values
>>>> inside the token itself, introspection gives a way to pass the values by
>>>> reference via the token as an artifact. The two are complementary, and
>>>> there are even cases where you'd want to deploy them together.
>>>>
>>>> -- Justin
>>>>
>>>>> On 7/28/2014 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> 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> 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
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Thomas Broyer
>>>>>> /t?.ma.b?wa.je/
>>>>>> _______________________________________________
>>>>>> 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
>>> _______________________________________________
>>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.ietf.org/mail-archive/web/oauth/attachments/20140729/a437e374/attachment.html>
------------------------------
Subject: Digest Footer
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
------------------------------
End of OAuth Digest, Vol 69, Issue 134
**************************************
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
