While this work addresses a gap in the existing OAuth specification set, I am
very concerned that this
incremental extension will lead to even more confusion around the areas of
“scope”, “audience” and “resource server”.
I think we should try to solve this problem via a framework that provides
confirmed -
prateek mishra
> On Sep 16, 2015, at 6:27 PM, Kepeng Li <kepeng@alibaba-inc.com> wrote:
>
> Hi Phil, Justin, William, Prateek ahd Hannes,
>
> I am working on the shepherd writeup for the PoP Architecture document:
> https://www.ietf.org/id/draft-ietf-o
[mailto:oauth-boun...@ietf.org]*On Behalf Of*John Bradley
*Sent:*Monday, February 09, 2015 3:31 PM
*To:*Prateek Mishra
*Cc:*oauth@ietf.org mailto:oauth@ietf.org
*Subject:*Re: [OAUTH-WG] Confusion on Implicit Grant flow
Typically the implicit callback JS is part of the application that is
already loaded
! There is no question in my mind that the review within
IETF would be more comprehensive and expose the work
to a larger community.
- prateek
On 6/12/2014 12:49 PM, Prateek Mishra wrote:
The OpenID Connect 2.0 COre specification alone is 86 pages. It has
received review from maybe a dozen
Excellent, now you have put your finger on the precise issue with OIDC -
lots of optional extensions and shiny trinkets and lack of a clear
definition of a core subset
for servers.
I realize its exciting for consultants, software and toolkit vendors to
have that sort of optionality, but in
-core-1_0.html#DynamicMTI
Mandatory to Implement Features for Dynamic OpenID Providers
-- Mike
-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Prateek Mishra
Sent: Friday, June 13, 2014 9:24 AM
To: Bill Burke; Phil Hunt
Cc: oauth@ietf.org
Subject: Re: [OAUTH
+1 to Hannes comments.
Hi Mike,
thanks for your quick response.
On 06/05/2014 07:46 PM, Mike Jones wrote:
Hannes, the Access Token and ID Token do quite different things and
have different structures and properties. The Access Token is an
opaque value that grants access to resources. An ID
The OpenID Connect 2.0 COre specification alone is 86 pages. It has
received review from maybe a dozen engineers within the OpenID community.
The a4c draft proposal is 15 pages and will receive review from 100s of
engineers within the world's most advanced standards body the IETF.
It's a no
Sergey - you haven't missed anything. The client remains unregistered
throughout the exchange.
There is no relationship between the assertion grant (or access token)
and the client either.
You are pointing out that an AS endpoint supporting unregistered clients
(public in OAuth terminology)
The difference between the two scenarios is that the authorization code
has a one-use property and also requires the user to be present.
These conditions are not available in the (assertion grant -- access
token) with a public client. So there are some fundamental differences
in security
Anil,
the challenge is that OIDC is a rather large set of specifications, and
to my knowledge even the core specification has NOT found
a complete implementation at any large IdP. I am not talking here about
boutique toolkits or startups, I am talking about the folks
who have 100s of millions
I hate to be one of these lets-be-careful guys, but I do have to point
out that the AWS documentation and method being referenced is
proprietary with its all attendant IP issues.
- prateek
Hi Hannnes,
Yes, so in terms of well-defined specs for HTTP request signing, there
is basically AWS,
key confirmed or key confirmation is another term that is widely
used for these use-cases
I really *like* the name proof of possession, but I think the
acronym PoP is going to be confused with POP. HOTK has the advantage
of not being a homonym for aything else. What about Possession Proof?
Bill - as you are referencing CORS in your message, I assume you are
discussing a Javascript-only (browser) client. I believe the implicit flow
was designed for this case and this flow never involves a confidential
client.
Confidential clients may be used with the other flows (code,
Well, this means you are completely dependent on a security model that
is based on a very specific property of HTTP
redirects. The User agent MUST NOT forward any component of a fragment
URI in a redirect - you are depending on the user having
a conformant and uptodate user agent.
I would say
from the auth server connection directly -- so the counter argument
is a bit of a red herring. Yes, it's a requirement for this to work properly,
but it's a requirement for many other things to work properly also.
-- Justin
On Feb 5, 2014, at 1:33 PM, Prateek Mishra prateek.mis...@oracle.com
Well, the proposed correction does point to a genuine security hazard
Specifically, when client instances share the same re-direct URI,
typically mobile clients
this is independent of whether implicit or code flows are used
It is only injective clients - each of whose instances bind to
ABSTRACT:
The objective of this project is to define application programming
interfaces and identity interaction models to facilitate the use and
creation of identity by Java applications. To meet this objective, this
specification defines a /representation for identity/ in Java, an
Karen,
I am planning to attend the meeting on Sunday.
However, I have made my travel plans based on your previous announcement
of 9/20
[quote]
2. Hold a oauth interop planning meeting in Vancouver in conjunction
with IETF#88.
This meeting is planned for:
Sunday, 3 November, 2013, 2:00 pm -
/is
testing pure OAuth functionality.
-- Mike
*From:*oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On
Behalf Of *Anthony Nadalin
*Sent:* Tuesday, October 08, 2013 4:22 AM
*To:* Prateek Mishra; IETF oauth WG
*Subject:* Re: [OAUTH-WG] Fwd: [oauth-interop] scope and reach of
testing activity
, 04 Oct 2013 16:48:50 -0700
From: Prateek Mishra prateek.mis...@oracle.com
Organization: Oracle Corporation
To: oauth-inte...@elists.isoc.org
Hello OAuth Interop list,
I would be interested in kicking off a discussion around the definition
of scope and reach of the proposed testing
Nat - is there cryptanalysis of the proposed model available anyplace?
Extending protocols by throwing in a smidgen of hashing and a tablespoon
of encryption is often a bad idea. One of the strengths of /RFC/ 6749 is
that it avoids stuff like that.
What do you mean when you say -
[quote]
1) As a JWT is always an instance of JWE or JWS, I am not sure why there
is a need for the the materials found in Section 5, para 1 (these are
also found in the JWE and JWS draft specifications). It could simply be
removed from the draft.
2) Why do we need both a typ claim and a typ header
Nat -
your blog posting is helpful to those of us who are looking for a
minimal extension of OAuth with
an authenticator. Many implementors are seeking a modest extension of
OAuth, not an entire new protocol
stack. I believe that is the point of Phil Hunt's proposal to the
OAuth committee.
Hi Manfred,
This is an area of interest to us and we have done some profiling in our
implementation.
Generally speaking, we work with the assertion profiles as a starting
point. They allow for WS-Trust
like token exchanges and (implicitly) support ActAs or OnBehalfOf. But
they do need
Todd - doesnt the AS have adequate scope information to guess which
resource server the token might get delivered to? I am afraid thats
about as far as the OAuth flows go in capturing the target of the
final request.
Couldn't the scope information be used by the AS to decide between
.
-- Mike
-Original Message-
From: prateek mishra [mailto:prateek.mis...@oracle.com]
Sent: Thursday, March 14, 2013 11:53 AM
To: Hannes Tschofenig; Mike Jones
Cc:oauth@ietf.org
Subject: the meaning of audience in SAML vs. OAuth
Hannes - you make a good point.
I believe that the usage
Agreed, Chuck - I need to respond to Brian's message of Feb 14 and
suggest proposed text for the draft. I plan to get to it in the next day
or two.
- prateek
Hey Prateek - and suggested improvements for the SAML Bearer draft?
On Mar 21, 2013, at 1:28 PM, prateek mishra wrote:
Mike, Nat
Hi Hannes,
I wanted to point out that use of the term audience in this document
is not consistent with the SAML 2.0 specification.
What you are referring to here as audience corresponds to
saml:destination which is described as
[quote-saml2.0]
Destination [Optional]
A URI reference
SAML supports a couple of SAML assertion reference formats, wherein
assertions are passed by reference.
One format is the artifact, which can be carried by a
saml:artifactthisisanartifactsaml:artifact element
Another possibility is the SAML URI binding which supports references of
the form
.
John B.
On 2013-02-28, at 2:56 PM, prateek mishra prateek.mis...@oracle.com
mailto:prateek.mis...@oracle.com wrote:
Characteristics of both these attacks -
1) Use of implicit flow (access token passed on the URL)
2) changes to redirect uri (specification does allow some flexibility
here)
3
On Mar 1, 2013, at 4:00 PM, prateek mishra wrote:
Yup, use of confidential clients and full checking of redirect URIs
would mitigate these attacks.
I think there is an issue of providing guidance to
developers/deployers, about making secure choices, that needs to be
addressed someplace
SAML 2.0 Profile for OAuth 2.0 Client Authentication and Authorization
Grants
JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants
Assertion Framework for OAuth 2.0 as above
a bit wordy, but does get the point across IMO
- prateek
I'm not sure anyone really picked the
Two points -
1) I request that this mailing list NOT be used for any substantive
discussion of patent claims and so on. This will create difficulties for
many participants and
I dont believe is within the charter of this effort.
2) I would encourage interested parties to review the
Characteristics of both these attacks -
1) Use of implicit flow (access token passed on the URL)
2) changes to redirect uri (specification does allow some flexibility here)
3) applications with long-lived access tokens with broad scope (in one
case only)
- prateek
And a different one (still
to the RS would work but relays on an implicit
assumption about what RS the client may present the token to otherwise all the
RS have to share private keys(probably a bad thing)
John B.
On 2013-02-14, at 4:20 PM, Prateek Mishra prateek.mis...@oracle.com wrote:
Justin - my comment was scoped
Justin - my comment was scoped to *key distribution* - not to the
general use of public clients.
I was wondering how one can distribute keys or have key agreement
between an AS and a client, if there is no existing trust relationship
between them. Maybe there is some
clever crypto way of
at the
point where an access token
is issued by the AS.
3) I think do need an MTI key distribution protocol as part of the
specification, leaving that as a choice would hurt interoperability.
- prateek
Here are my notes.
Participants:
* John Bradley
* Derek Atkins
* Phil Hunt
* Prateek Mishra
It would be helpful if the draft identified the various cases that are
intended to be supported. For example,
in draft-ietf-oauth-assertions-10, there is a helpful distinction made
between Client acting on behalf of a user vs.
Client Action on behalf of an anonymous user (vs. even more advanced
Can you explain how SSLstrip could be used to defeat the OAuth flows?
Isn't it dependent on web pages with non-HTTPs links?
Which step in the OAuth exchanges would be vulnerable?
BTW, there is a threats analysis document that discusses a variety of
attacks and countermeasures -
Bill -
How does OAuth 1.0a deal with the problem of HTTP URL and header
mutability? Header order may get re-arranged and URLs modified in
transit from client to server. As a result, the signature/HMAC
might not validate at the final destination.
Isn't that a foundational problem with the
Hannes - here a couple of comments on the 05 draft -
(i) Section 4 -
[quote]
Note however, that the set of claims that a JWT must contain to be
considered valid is context-dependent and is outside the scope of this
specification. When
used in a security-related context, implementations MUST
Pedro - the best way to move this forward is to make a proposal or
describe some use-cases.
My own guess is that we also need a broader discussion of different
client-types and their deployment models.
For example, there are clients that are delivered through a secured
process to tablets or
Sent from my Verizon Wireless Phone___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
+1
finishing a draft for historical reasons without the full context of HoK
use-cases and identified threats concerns me
In Vancouver the question was asked about the future of the MAC spec
due to it no linger having a editor.
The Chair and AD indicated a desire to have a document on the
check, but that could just be included
in token anyway without holder-of-key.
I really don't see how this works with symmetric keys in any useful way that's
not easier via another method like MAC tokens?
From: prateek mishra prateek.mis...@oracle.com
To: Tschofenig, Hannes (NSN - FI/Espoo
As Phil Hunt suggests, there is a need for a discussion of the use-cases
involved
How to bind the key to the requestor may have several variations, I
would hope the work would cover a broad range
Given the importance of the symmetric key case, I would also be
interested in key establishment
Francisco,
You are right, I was in error to suggest that it was a MUST.
I think my main concern was that security considerations should not be
based on polling developers/deployers of an existing or legacy protocol.
SAML does include some additional countermeasures though - for example
+1 on #3
from an enterprise perspective, we really dont want applications/clients
to have embedded knowledge of the security model for any target resource.
As I understand this proposal, this would allow a security component at
the client site/device to discover and create the right type of
George,
I will comment at a later time on the details of your use-case.
But as far as signing the request for a protected resource (signature
over access token, client_id, scope, URL, request body) - isn't this
requirement is a simple consequence of network architecture wherein an
SSL
for your advice. The Oauth security considerations are not finished yet. They will handle the issues you raised, too.
Regards,
Torsten.
Am 30.09.2010 um 01:33 schrieb PRATEEK MISHRA prateek.mis...@oracle.com:
I read through v10 from the perspective of an implementor, and it seemed to me
I read through v10 from the perspective of an implementor, and it seemed
to me that properties of generated authorization code and its treatment
by various entities need to be called out explicitly as a
counter-measure against various simple attacks.
I would also comment that the exchanges
Brian,
it would probably help to clarify that you are proposing this as a
additional or follow-on step to SSO implemented via the SAML web browser
profiles (right?).
Maybe some text could be added to the draft to make that explicit. This
is in contrast to more general token exchange
Do you mean April 29 (Thu) and April 30th (Fri)?
This is a call for consensus on accepting Eran's latest OAuth draft,
draft-hammer-oauth2 [1] as a working group item. Assuming no
objections by end-of-day Tuesday, April 22nd, this draft will be
promoted to an active working group document on
54 matches
Mail list logo
