That’s not a minimalistic authn only profile.
If you return both an access token AND an id token than the service provide has
to implement both and the client has to figure out what to do with it.
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On May 14, 2014, at 5:44 PM, Chu
"I had personally requested the OIDC community about six months ago to
describe some minimal subset which we could all reasonably implement."
I believe you're looking for this:
http://openid.net/specs/openid-connect-basic-1_0.html
-cmort
On Wed, May 14, 2014 at 5:37 PM, Prateek Mishra
wrote:
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 o
a4c is connect.For example here's the sample requests:
draft-hunt-oauth-v2-user-a4c-01, section 2.1:
GET /authenticate?
response_type=code
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.com%2Fcb
&state=af0ifjsldkj
&prompt=login
Host: server.exampl
Forgive me if this is well-trodden territory, but I would have expected the
security considerations in this proposal to include a note to the effect of:
"In a scenario where a mobile client is contending with malicious apps on
the same device that listen on the same custom URL scheme, it's importa
I did an implementation of
http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03 last week. We are
seeing growing demand for some kind of solution to the code callback
interception attack. The industry needs a well documented standard solution.
On Wed, May 14, 2014 at 3:16 PM, Anthony Nadalin w
I have been told that DT has a implementation and I know Google is using it for
the apps they publish on iOS and perhaps other places, though they may use pre
Draft parameter names currently.
There are some others I have talked to, but I will need to get there permission
to disclose there names
There are folks that are not implementing connect for various reasons (i.e.
security reasons, complexity reasons, etc.). thus this is compatible with
connect if folks want to move on to connect, we surely don’t use connect
everwhere as it’s over kill where we only need a the functionality of a4
Please list the implementstions
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
Sent: Wednesday, May 14, 2014 10:59 AM
To: Brian Campbell
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering
I know a number of people implementing
http://tools.
nice one Mike et al!!
well deserved!
regards
antonio
On May 14, 2014, at 8:19 PM, Mike Jones
mailto:michael.jo...@microsoft.com>> wrote:
Today the JSON Web Token (JWT) and JSON Object Signing and Encryption (JOSE)
specifications were granted a Special European Identity Award for Best
Innova
Today the JSON Web Token (JWT) and JSON Object Signing and Encryption (JOSE)
specifications were granted a Special European Identity Award for Best
Innovation for Security in the API Economy. I was honored to accept the award,
along with Nat Sakimura and John Bradley, on behalf of the contribut
I know a number of people implementing
> http://tools.ietf.org/html/draft-sakimura-oauth-tcse-03
Having it on a RFC track may make sense.
I remain to be convinced that a4c ads anything other than confusion.
If the WG wants to take it up it should be aligned with Connect. I think there
are m
Phil, neither is Connect an authentication mechanism, it (and SAML,
WS-fed etc) is also a 'method for providing end-user authentication
information to client applications'
We don't need a Connect--
paul
On 5/14/14, 1:29 PM, Phil Hunt wrote:
This is not an authentication mechanism - it is a met
Would still love to hear you answer _why_ "the IETF needs a draft that
enables and provides user authentication information to clients."
Would still love to see Tony point to the existing a4c implementations.
On Wed, May 14, 2014 at 10:29 AM, Phil Hunt wrote:
> This is not an authentication
This is not an authentication mechanism - it is a method for providing end-user
authentication information to client applications. I will publish a revised
draft shortly.
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On May 14, 2014, at 10:23 AM, George Fletcher wrote:
>
Tony/Phil,
any chance you can have this work done at OIDC?
The reason is that it is commonly understood/accepted now that OAuth
provides authorization related specs while authentication/profile
related specs are coming from OIDC (which builds on top of OAuth2).
Regards,
Anil
On 05/14/2014 1
I also would like to see the WG not focus on another authentication
mechanism and instead look at work like Brian suggested.
Thanks,
George
On 5/14/14, 11:41 AM, Chuck Mortimore wrote:
Agree with Brian and Justin here. Work is already covered in Connect
- cmort
On May 14, 2014, at 8:39 AM,
>
>
> The IETF needs a draft that enables and provides user authentication
> information to clients.
>
Why?
-cmort
>
> Phil
>
> @independentid
> www.independentid.com
> phil.h...@oracle.com
>
>
>
> On May 14, 2014, at 9:39 AM, Chuck Mortimore
> wrote:
>
> Can you point to one publicly availabl
For the record, we adjusted draft 01 to make it more compatible with OIDC at
the request of the Connect community. I agreed to change it because I can
agree that it is a good stepping stone for adoption of Connect. Others may
prefer to have a cleanly separate method. I leave that for the group
Can you point to one publicly available or publicly documented
implementation of a4c?I've never seen one.
I will say the a4c spec is almost 100% overlapped with OpenID Connect.
Some minor variations in claim names, but it adds 0 incremental value over
what we have in Connect.
Connect is being
I think there's a use case for this work that may or may not be covered by the
PoP spec, and in fact I think this work is related to that. The MAC token work
is really one use case of POP tokens. Rather than shouting it down let's
figure out how to solve this use case.
On Wednesday, May 14,
I agree with Phil on this one, there are implementations of this already and
much interest
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Phil Hunt
Sent: Wednesday, May 14, 2014 8:32 AM
To: Brian Campbell
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth Milestone Update and Rechartering
I agree with Brian and object to the Authentication work item. I think there’s
limited interest and utility in such a draft, especially now that OpenID
Connect has been published and its core authentication capabilities are
identical to what was called for in the other draft a year ago (a simila
Agree with Brian and Justin here. Work is already covered in Connect
- cmort
On May 14, 2014, at 8:39 AM, Justin Richer wrote:
I agree with Brian and object to the Authentication work item. I think
there’s limited interest and utility in such a draft, especially now that
OpenID Connect has be
On the contrary. I and others are interested.
We are waiting for the charter to pick up the work.
Regardless there will be a new draft shortly.
Phil
> On May 14, 2014, at 5:24, Brian Campbell wrote:
>
> I would object to 'OAuth Authentication' being picked up by the WG as a work
> item. T
I would object to 'OAuth Authentication' being picked up by the WG as a
work item. The starting point draft has expired and it hasn't really been
discusses since Berlin nearly a year ago. As I recall, there was only very
limited interest in it even then. I also don't believe it fits well with
the
That too would suggest that the length limit be on code_challenge because
that's the parameter that will be on URIs getting passed around. The
code_verifier is sent directly in the POST body from client to AS.
On Tue, May 13, 2014 at 12:52 AM, Nat Sakimura wrote:
> +1 for octet. We used to have
Hi
Section 3.2 [1] mentions that "If the algorithm is
registered, the server MUST reject any request that does not conform
to the algorithm"
I wonder is this text adds anything extra in addition to what Section
3.7 [2] says where the server is required to reject the request if the
verifier and
Hi
On 13/05/14 16:27, Justin Richer wrote:
Blair,
You’re right in that the MAC draft is effectively abandoned now as the
WG has moved on to other signed-token mechanisms. As part of that
effort, I’ve put together a JWS-based HTTP request signature mechanism
(referenced in Hannes’s presentation):
29 matches
Mail list logo
