+1 support for adoption. This draft is useful for PCP third party authorization
http://tools.ietf.org/html/draft-wing-pcp-third-party-authz-03, where PCP
server in the Enterprise network (Resource server) and WebRTC server
(Authorization server) are in different administrative domains. PCP third
I think this perspective has a lot to do with your idea of OAuth's
deployment model. You're right in that many people bundle the RS and the
AS very tightly, but that's not always case, nor is it desirable. We're
increasingly seeing cases where a group (often an enterprise) has their
own AS on p
Interesting question.
In our specific case, we don't really *need* interop as we have a single
AS, so the protocol could be specific to our needs. Building on a standard
however means that it might be easier to find software libraries
implementing it that could be used to build apps for our platfo
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.
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
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 i
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 I
I support the WG taking this on
On 7/28/14, 1:33 PM, Hannes Tschofenig wrote:
Hi all,
during the IETF #90 OAuth WG meeting, there was strong consensus in
adopting the "OAuth Symmetric Proof of Posession for Code Extension"
(draft-sakimura-oauth-tcse-03.txt) specification as an OAuth WG work ite
Yes, I am in favor of adopting this document as a WG work item.
On Mon, Jul 28, 2014 at 11:33 AM, Hannes Tschofenig <
hannes.tschofe...@gmx.net> wrote:
> Hi all,
>
> during the IETF #90 OAuth WG meeting, there was strong consensus in
> adopting the "OAuth Symmetric Proof of Posession for Code Ex
+1 adoption
On Monday, July 28, 2014 11:41 AM, Hannes Tschofenig
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
Yes. This spec is of particular interest to UMA, for which it's valuable to
have a standardized and interoperable way to perform run-time token
introspection at the AS. To see how UMA uses profiles the existing token
introspection spec, see this section and its subsections:
http://tools.ietf.or
Hi all,
during the IETF #90 OAuth WG meeting, there was strong consensus in
adopting the " Request by JWS ver.1.0 for OAuth 2.0"
(draft-sakimura-oauth-requrl-05.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 l
Hi all,
during the IETF #90 OAuth WG meeting, there was strong consensus in
adopting the "OAuth 2.0 Token Exchange"
(draft-jones-oauth-token-exchange-01.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. Her
Hi all,
during the IETF #90 OAuth WG meeting, there was strong consensus in
adopting the "OAuth Symmetric Proof of Posession for Code Extension"
(draft-sakimura-oauth-tcse-03.txt) specification as an OAuth WG work item.
We would now like to verify the outcome of this call for adoption on the
OAut
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. He
15 matches
Mail list logo
