Indicating the resource server to the AS allows the AS to automatically select
token type, encryption scheme and user data to be put into the access token
based on a RS-specific policy. So there is no need to explicitely ask the AS
for a certain token format or encryption scheme.
> Am 11.04.20
I am objecting to modifying the protocol in the default case as a majority do
not need RI in the case of fixed endpoints.
Migration would be challenging because the change is breaking and affects
existing clients.
Dynamic discovery are up and coming cases and a relatively green field. Dealing
No, no especial need at this time. It was more out of curiosity, you guys
did a great work...and quick too!
I mean, It's just nice for a new project in Swift to be able to work with
Swift libraries instead of having to mock with bridging files and @objc
annotations. But again, not a strong reason
I will work to try and clarify in the next draft but would happily listen
to suggestions.
On Mon, Apr 11, 2016 at 2:26 PM, Brian Campbell
wrote:
> The intent is that urn:ietf:params:oauth:token-type:access_token be an
> indicator that the token is a typical OAuth access token issued by the AS
>
So it’s an incomplete solution then ?
From: Brian Campbell [mailto:bcampb...@pingidentity.com]
Sent: Monday, April 11, 2016 1:34 PM
To: Anthony Nadalin
Cc: Nat Sakimura ;
Subject: Re: [OAUTH-WG] Call for Adoption: Resource Indicators for OAuth 2.0
No, I'm not adding requirements for encryption
No, I'm not adding requirements for encryption. I was pointing out some of
the ways that an access token might be different for different RSs.
On Mon, Apr 11, 2016 at 2:18 PM, Anthony Nadalin
wrote:
> So now you are adding more requirements for encryption ? The more this
> thread goes on shows
The intent is that urn:ietf:params:oauth:token-type:access_token be an
indicator that the token is a typical OAuth access token issued by the AS
in question, opaque to the client, and usable the same manner as any other
access token obtained from that AS (it could well be a JWT but the client
isn't
So now you are adding more requirements for encryption ? The more this thread
goes on shows how unstable and not fully thought out this draft is to go
through WG adoption.
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Monday, April 11, 2016 12:30 PM
To: Nat Sakimu
+1
On Thu, Apr 7, 2016 at 12:25 PM, Mike Jones
wrote:
> Yes - an intentionally conservative, implementation- and experience-driven
> path.
>
> Revising OAuth 2.0 is a *big deal*. We shouldn't even be talking about it
> until we've completed steps 1-5 below - *including* the "iterate" step, as
>
Sending a token type is not sufficient. There's more involved than the
format. Many cases need to know if to encrypt and whom to encrypt to. What
claims to put in the token (or reference by the token). What algorithms and
keys to use for signing/encryption.
The statement that the "Current proposa
I'm not sure where the idea that it's only applicable to special uses like
collaboration services is coming from. The pattern described in the draft
(using a different parameter name but otherwise the same) is deployed and
in-use for normal OAuth cases including and especially the resource owner
ce
Antonio,
you should recommend him/her your new OAuth book! This may help to get
some of the misconceptions about OAuth clarified!
Ciao
Hannes
On 04/11/2016 09:04 AM, Antonio Sanso wrote:
> Just sharing, do not shoot the messenger :)
>
> http://insanecoding.blogspot.com/2016/04/oauth-why-it-does
I am finding I am not happy with solving the bad resource endpoint config issue
with resource indicator. At best I see this as a special use draft for things
like collab services or things which aren't resource owner centric.
Yet resource endpoint config is a concern for all clients that config
We are implementing the experimental RFC 7592 in our distributed ASP.NET Core
OAuth2 farm. Based on our experience to date, we have a few concerns and
suggestions to add to the conversation. Hopefully these are helpful.
[P.S. Generally the RFC is strong. Kudos to the RFC 7592 authors.]
1. S
Hi,
There are multiple places in draft-ietf-oauth-token-exchange-04 where a
differentiation seems to be drawn between 'access_token' and 'jwt' ... for
example in section 2.2.1. when discussing the issued_token_type, it states:
a value of "urn:ietf:params:oauth:token-type:access_token" indic
Under the Token Exchange part it says, "Jim Fenton: we have implmentation
that could be adapted to this." but, as I recall, Jim was not speaking for
himself there but rather on behalf of Justin via the Jabber room.
On Wed, Apr 6, 2016 at 11:43 AM, Hannes Tschofenig <
hannes.tschofe...@gmx.net> w
hi Hans,
indeed I found this article technically inaccurate and it annoyed me quite a
bit…
regards
antonio
On Apr 11, 2016, at 9:26 AM, Hans Zandbelt wrote:
> "JWT is a specification for allowing SSO or API usage between services. In
> many ways JWT is like SAML"
>
> makes me stop trying t
"JWT is a specification for allowing SSO or API usage between services.
In many ways JWT is like SAML"
makes me stop trying to parse/understand the rest of it
Hans.
On 4/11/16 9:04 AM, Antonio Sanso wrote:
Just sharing, do not shoot the messenger :)
http://insanecoding.blogspot.com/2016/04/o
Just sharing, do not shoot the messenger :)
http://insanecoding.blogspot.com/2016/04/oauth-why-it-doesnt-work-and-how-to-zero-day-attack.html
and companion website:
http://no-oauth.insanecoding.org/
regards
antonio
___
OAuth mailing list
OAuth@ietf.
19 matches
Mail list logo
