;
> Thanks!
>
> V.
>
>
>
> *From: *OAuth on behalf of Prabath Siriwardena
>
> *Date: *Thursday, May 7, 2020 at 11:56
> *To: *Rifaat Shekh-Yusef , oauth
> *Subject: *[OAUTH-WG] [JWT Profile for OAuth 2.0 Access Tokens] Adding
> state into the JWT
>
>
>
Hi all,
Can we say in [1], that the AS should add the value of *state* parameter
from the authorization request (if present), to the JWT access token it
generates?
This will help to address token injection issue [2], with respect to the
implicit grant type.
Appreciate your thoughts on this.
[1]
that we can look at the details.
>
> On 04/15/2015 01:30 PM, Prabath Siriwardena wrote:
> > Hi Hannes,
> >
> > I still think its equally important to have a transport independent
> > binding ..
> >
> > If you look at the SOAP world, WS-Security is self-cont
e wants to figure out how to carry OAuth access tokens over
> MQTT then they will have to figure out whether there are some additional
> considerations to take into account.
>
> What we should probably doing in this group is to write a guidance
> document for using OAuth over <&g
5 at 2:55 PM, John Bradley wrote:
> Most of the pub sub things I have seen use HTTP transport. Do you have a
> pointer to the protocol?
>
> On Apr 14, 2015, at 6:48 PM, Prabath Siriwardena wrote:
>
> Thanks John for the pointer - will have look..
>
> I am looking
>
> Is there something specific that you are looking for that is not covered
> by SASL?
>
> John B.
>
>
>
> On Apr 14, 2015, at 6:21 PM, Prabath Siriwardena wrote:
>
> At the moment we only HTTP binding to transport the access token (please
> correct me if not)..
At the moment we only HTTP binding to transport the access token (please
correct me if not)..
This creates a dependency on the transport.
How about creating a JWT binding for OAuth 2.0..? We can transport the
access token as an encrypted JWT header parameter..?
Thanks & Regards,
Prabath
Twitte
Is the $subject still active...?
http://tools.ietf.org/html/draft-hunt-oauth-chain-01
I guess it would be more meaningful to add an "audience" parameter to the
chained token request..
WDYT..?
Thanks & Regards,
Prabath
Twitter : @prabath
LinkedIn : http://www.linkedin.com/in/prabathsiriwardena
https://tools.ietf.org/html/draft-richer-oauth-introspection-04
token_type_hint OPTIONAL. A hint about the type of the token submitted
for *revocation*.
I guess *revocation* should be corrected as *introspection* ?
Thanks & Regards,
Prabath
Twitter : @prabath
LinkedIn : http://www.linkedin.co
r
> token" work forward and there will be changes to what is currently in
> this document.
>
> So, I would encourage you to wait a few weeks and you will the updated
> version of the document.
>
> Ciao
> Hannes
>
>
> On 03/28/2014 01:10 AM, Prabath Siriwardena
Do we have any public implementations of OAuth 2.0 MAC Token Profile..?
[1]: http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-05
Thanks & Regards,
Prabath
Twitter : @prabath
LinkedIn : http://www.linkedin.com/in/prabathsiriwardena
Mobile : +94 71 809 6732
http://blog.facilelogin.com
ht
Currently the introspection response has an optional parameter to pass the
client_id to the caller. It would also be useful to pass an ID token back
in the response - just like in OpenID Connect - to include end user details.
WDYT ?
Thanks & regards,
-Prabath
On Tue, Nov 12, 2013 at 3:27 AM, Nat
Congrats..!!! Its been a great - highly extensible framework which can be
leveraged to address many aspect in REST security...
Thanks & regards,
-Prabath
On Wed, May 15, 2013 at 10:54 PM, Mike Jones wrote:
> I’m pleased to report that OAuth 2.0 has won the 2013 European Identity
> Award for Bes
Yes. If its a new grant asking an access token with a new scope - then we
need to give a new acces token.
Thanks & regards,
-Prabath
On Fri, May 17, 2013 at 6:13 AM, Phil Hunt wrote:
> My understanding is this is ok if during authorization, the client
> requested at least "foo1 bar1 foo2" or "f
-Prabath
On Tue, Feb 12, 2013 at 9:35 PM, Prabath Siriwardena wrote:
> Hi Justin,
>
> I doubt whether valid_token would make a difference..?
>
> My initial argument is what is the validation criteria..? Validation
> criteria depends on the token_type..
>
> If we are talki
t; together?
>
> -- Justin
>
>
> On 02/11/2013 08:02 PM, Richard Harrington wrote:
>
> Have you considered "status" instead of "valid"? It could have values
> like "active", "expired", and "revoked".
>
> Is it worthwh
ly..
May be can add "revoked" with a boolean attribute..
Thanks & regards,
-Prabath
On Tue, Feb 12, 2013 at 3:19 AM, Justin Richer wrote:
>
> On 02/08/2013 12:51 AM, Prabath Siriwardena wrote:
>
> Hi Justin,
>
> I have couple of questions related to "val
Hi Justin,
Any thoughts on the following...
Thanks & regards,
-Prabath
On Fri, Feb 8, 2013 at 11:21 AM, Prabath Siriwardena wrote:
> Hi Justin,
>
> I have couple of questions related to "valid" parameter...
>
> This endpoint can be invoked by the Resource Server i
also
> got "access" vs. "refresh" and other flavors of token, like the id_token in
> OpenID Connect.
>
> Thing is, the server running the introspection endpoint will probably know
> *all* of these. But should it tell the client? If so, which of the three,
> and
h a pure JSON response.
>
> -- Justin
>
>
> On 02/06/2013 10:47 PM, Prabath Siriwardena wrote:
>
> Hi Justin,
>
> I believe this is addressing one of the key missing part in OAuth 2.0...
>
> One question - I guess this was discussed already...
>
> In the spe
ng this draft. And the open issues
> > discussed on the list in the last couple of weeks illustrate that
> > even this poses a considerable amount of work. So I'm very reluctant
> > to add support for a whole new use case at that point of the process.
> >
> > If you
Hi Justin,
I believe this is addressing one of the key missing part in OAuth 2.0...
One question - I guess this was discussed already...
In the spec - in the introspection response it has the attribute "valid" -
this is basically the validity of the token provided in the request.
Validation cri
hole new use case at that point of the process.
>
> If you feel this is an important use case worth an RFC, don't hesitate to
> publish a new I-D.
>
> regards,
> Torsten.
>
> Am 06.02.2013 um 16:37 schrieb Prabath Siriwardena :
>
>
>
> On Wed, Feb 6, 2013 at 9:04
if it's a general attack on SSL
> transport for the browser?
>
Yes.. its a general attack against SSL and counter measures defined too..
Thanks & regards,
-Prabath
> ----------
> *From:* Prabath Siriwardena
> *To:* William Mills
> *Cc:* L.
On Mon, Feb 4, 2013 at 9:57 PM, William Mills wrote:
> There are two efforts at signed token types: MAC which is still a
> possibility if we wake up and do it, and the "Holder Of Key" type tokens.
>
If someone can use sslstrip then even MAC is not safe - since MAC key needs
to be transferred over
nd the scope. So
AS can revoke access.
Thanks & regards,
-Prabath
>
> *
>
>
> Todd Lainhart
> Rational software
> IBM Corporation
> 550 King Street, Littleton, MA 01460-1250**
> 1-978-899-4705
> 2-276-4705 (T/L)
> lainh...@us.ibm.com*
>
>
>
>
>
MA 01460-1250**
> 1-978-899-4705
> 2-276-4705 (T/L)
> lainh...@us.ibm.com*
>
>
>
>
> From:Justin Richer
> To:Prabath Siriwardena ,
> Cc:"oauth@ietf.org WG"
> Date:02/06/2013 10:21 AM
> Subjec
On Wed, Feb 6, 2013 at 8:49 PM, Justin Richer wrote:
>
> On 02/06/2013 10:13 AM, Prabath Siriwardena wrote:
>
>
>
> On Wed, Feb 6, 2013 at 8:19 PM, Justin Richer wrote:
>
>> These are generally handled through a user interface where the RO is
>> authenticate
f you revoke the entire token then Client
needs to go through the complete OAuth flow - and also needs to get the
user consent. If RO can downgrade the scope, then we restrict API access
by the client at RS end and its transparent to the client.
Thanks & regards,
-Prabath
>
>
> --
ent to revoke. Resource owner should have
the capability to revoke an acces token by client.
Thanks & regards,
-Prabath
>
> *
>
>
> Todd Lainhart
> Rational software
> IBM Corporation
> 550 King Street, Littleton, MA 01460-1250**
> 1-978-899-4705
> 2-276-4705 (T
I am sorry if this was already discussed in this list..
Looking at [1] it only talks about revoking the access token from the
client.
How about the resource owner..?
There can be cases where resource owner needs to revoke an authorized
access token from a given client. Or revoke an scope..
How
FYI and for your comments..
http://blog.facilelogin.com/2013/02/why-oauth-it-self-is-not-authentication.html
Thanks & Regards,
Prabath
Mobile : +94 71 809 6732
http://blog.facilelogin.com
http://RampartFAQ.com
___
OAuth mailing list
OAuth@ietf.org
htt
Here are some references that I found they do not.. thoughts appreciated...
1. https://developers.facebook.com/docs/howtos/login/login-as-app/
2. https://developers.facebook.com/docs/howtos/login/extending-tokens/
3. https://developers.facebook.com/docs/howtos/login/login-as-page/
Thanks & Regard
it's token requirements via WS-SecurityPolicy,
in WSDL. And client reads the WSDL and identify the token requirements.
Then based on those requirements, client talks to the STS and gets the
token.
Thanks & regards,
-Prabath
On Mon, Jan 21, 2013 at 1:07 PM, wrote:
>
> Prabath Siriwarde
to request a type, but it may not get it.
>
> I don't object client requesting a type, but I think it is meaningful only
> when the requested type is specified by a RS,
> and client just relay that request to AS.
>
> >
> > From: "zhou.suj...@zte.com.cn"
&g
t; > what token type is in play. Likely a good extension to the spec.
>
> >
> > From: Prabath Siriwardena
> > To: "oauth@ietf.org WG"
> > Sent: Sunday, January 20, 2013 7:28 PM
> > Subject: [OAUTH-WG] Client cannot specify the token type it needs
>
Although token type is extensible according to the OAuth core specification
- it is fully governed by the Authorization Server.
There can be a case where a single AS supports multiple token types based
on client request.
But currently we don't have a way the client can specify (or at least
sugges
he mapping between the user
> > request and the code is broken.
> >
> > Thanks & regards,
> > -Prabath
> >
> >
> >
> > Best Regards
> > Brent
> >
> > 2013/1/9 Prabath Siriwardena :
> > > Prabath
> >
>
> >
> >
uest and code.. Adding user name
or any identifier to the message sending from AS to Client won't help.
Because browser request has to identify it self.
Thanks & regards,
-Prabath
>
>
> Best Regards
>
> Brent
>
>
>
> On Wed, 9 Jan 2013 12:17:19 +0530, Prabath S
the authorization code via User Agent - links
the user request to the authorization code. If AS directly sends the code
to the Resource Server the mapping between the user request and the code is
broken.
Thanks & regards,
-Prabath
>
> Best Regards
> Brent
>
> 2013/1/9 Prab
Hi Brent,
Few points, why this doesn't create any security implications..
1. Authorization server maintains a binding to the Client, who the token
was issued to. To exchange this to an Access token client should
authenticate him self.
2. Code can only be exchanged once for an acces token.
Thanks
t can do that without the RO's
> synchronous presence would be ideal. Otherwise I suspect it's impractical
> in normal use.
>
> Eve
>
> On 9 Oct 2012, at 6:49 PM, zhou.suj...@zte.com.cn wrote:
>
>
> Hi，Prabath
>
>
> *Prabath Siriwardena *
>
> 2012-10
is directed by RS to AS to obtain access-token,AS may request RO to
> authenticate and confirm the
> access-token request
> 3. Client accesses the protected resource on behalf of the Resource Owner.
>
>
>
There needs to be an step to facilitate client registration.
Thanks &
his subject, and published a draft on it. *
> **http://tools.ietf.org/id/draft-zhou-oauth-owner-auth-00.txt*<http://tools.ietf.org/id/draft-zhou-oauth-owner-auth-00.txt>
> I'd like to have your opinion.
>
>
> *Prabath Siriwardena <**prab...@wso2.com* *>*
> 发件人
; regards,
-Prabath
On Sun, Oct 7, 2012 at 6:24 PM, wrote:
>
> Hi, Praba
>
> I am also thinking on this subject, and published a draft on it.
> http://tools.ietf.org/id/draft-zhou-oauth-owner-auth-00.txt
> I'd like to have your opinion.
>
>
>
> *Prabath
.
>
> We'll be walking through UMA flows and demoing an extensive use case at a
> webinar on Wed, Oct 17. More info is here: http://tinyurl.com/umawg
>
> Hope this helps,
>
> Eve
>
> On 6 Oct 2012, at 10:29 AM, Prabath Siriwardena wrote:
>
> >
Hi folks,
I would like to know your thoughts on the $subject..
For me it looks like a concrete use case where OAuth conceptually does
address - but protocol does not well defined..
Please find [1] for further details...
[1]:
http://blog.facilelogin.com/2012/10/ationwhat-oauth-lacks-resource-ow
47 matches
Mail list logo
