Mike,
Deal. :-)
Paul
> -Original Message-
> From: Mike Jones [mailto:michael.jo...@microsoft.com]
> Sent: Friday, April 20, 2012 1:49 AM
> To: Paul E. Jones; 'Murray S. Kucherawy'; oauth@ietf.org; 'Apps Discuss'
> Subject: RE: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery
Oh, don't scare people with that ;-)
If we do extend the syntax of WF, we should ensure that both formats are
extended in a natural way for each format. Backward compatibility should
also be of utmost concern, so changes should never be too drastic.
Paul
> -Original Message-
> From: Goi
To be clear, making this mandatory would break no clients. It would require
updating some servers, just as requiring JSON would. This seems like a fair
tradeoff when it makes an appreciable difference in user interface latency in
some important scenarios. If you and the other key WebFinger su
Tim,
I misunderstood. I thought you authored the MNOT blog post. That stood in
quite a contrast to your work on XML. Reading that, I felt like, on a whim,
you threw the baby out with the bathwater and started down a new path,
giving no regard to what exists.
OK, let me reset me mind dizzy head
That's correct. We could certainly make it mandatory, but the reason it
isn't is to maintain backward compatibility with existing deployments.
I think we should always think carefully when we decide to make a change
that breaks backward-compatibility. This is one change that would do that.
Paul
I agree, requirements are more important than deciding on the starting
document at this point.
I don't care about the name at all. The proposals are not wolds apart.
I suspect if we can agree on the requirements for the number of requests most
of the other decisions will fall out of that.
Currently, support for the "resource" parameter is optional, as per the
following (correct?):
Note that support for the "resource" parameter is optional, but
strongly RECOMMENDED for improved performance. If a server does not
implement the "resource" parameter, then the server's host me
Tim,
I do not agree that it's harmful. If I removed the WF discussion off the
table, I'm still having a hard time buying into everything you said in the
blog post.
I implement various web services, largely for my own use. Usually, I
implement all of them in XML, JSON, plain text (attribute/value
Mike,
> There are two criteria that I would consider to be essential requirements
> for any resulting general-purpose discovery specification:
>
> 1. Being able to always discover per-user information with a single GET
> (minimizing user interface latency for mobile devices, etc.)
WF can do tha
Various additional anti-abuse controls can be applied like CAPTCHA if you have
a full browser to leverage. Much harder to get that flexibility in a fixed
client UI.
>
> From: Paul Madsen
>To: adam.le...@motorolasolutions.com; jric...@mitre.org
>Cc: oauth@i
The goal is to train users to use a trusted browser to enter credentials rather
than an embedded app that is phishing there authentication credentials.
The other advantage is that if there are multiple apps the browser can maintain
session state across provisioning tokens for multiple apps with
Hi Brian,
I was also looking at the resource owner credentials flow, but it seems limited
to username & password ... it's not clear that it would work with stronger
authentication methods such as RSA. Thoughts?
adam
From: Brian Campbell [mailto:bcampb...@pingidentity.com]
Sent: Thursday, Apri
Hi Paul,
So by saying ‘more easily’ then there is nothing really inherently preventing a
native implementation from making the HTTP calls to the AS directly, right?
My use cases are a bit atypical from the web service driven models that you
guys are solving, but I think the technology should st
A browser isn't required. The browser based flows are pretty common with
OAuth but they are certainly not the only way to get a token.
The resource owner credentials and client credentials grant types are both
involve only direct communication between the client and the AS. And there
are also the
Using the browser as part of the AS interaction allows you to more easily
collect the users consent.
Once you get the tokens based on that consent, everything is 'RESTful'
Original message
Subject: Re: [OAUTH-WG] Using OAuth to get a JWT/SAML token
From: Lewis Adam-CAL022
To:
Hi Justin,
There is one thing I have not understood about the whole external browser vs.
embedded browser guidance ... and that is, why is *any* browser needed? Java
for example has an HTTP library, and OAuth is RESTful. So why is it necessary
to require the web browser at all, whether extern
On 19 April 2012 23:12, Melvin Carvalho wrote:
>
>
> On 19 April 2012 20:26, Eran Hammer wrote:
>
>> #1 as John Panzer identified, allowing the server to control its
>> deployment and supporting HTTP redirects is critical.
>>
>
> +1
>
>
>> #2 JSON is better, which one is required is less of on i
On 19 April 2012 20:26, Eran Hammer wrote:
> #1 as John Panzer identified, allowing the server to control its
> deployment and supporting HTTP redirects is critical.
>
+1
> #2 JSON is better, which one is required is less of on issue but more of a
> best practices item.
>
Happy with this comm
Hi Mike,
Am 19.04.2012 18:48, schrieb Mike Jones:
There are two criteria that I would consider to be essential requirements for
any resulting general-purpose discovery specification:
1. Being able to always discover per-user information with a single GET
(minimizing user interface latency fo
Hi Justin,
In my opinion, the OpenID Connect introspection/checkid endpoint is a
convenience function for clients (not resource servers) unable to
decrypt id tokens and validate their signatures. I'm not convinced this
function is needed, that's why I proposed to drop it.
The AS-PR endpoint
#1 as John Panzer identified, allowing the server to control its deployment and
supporting HTTP redirects is critical.
#2 JSON is better, which one is required is less of on issue but more of a best
practices item.
I'll add:
* Highly cachable
* Optimize for large providers, reducing the need to
I agree that redirects need to be followed, when used.
-- Mike
From: John Panzer
Sent: 4/19/2012 7:04 PM
To: Mike Jones
Cc: Murray S. Kucherawy; oauth@ietf.org WG; Apps Discuss
Subject: Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD)
On Thu
+1 on the requirements.
On 4/19/2012 12:48 PM, Mike Jones wrote:
There are two criteria that I would consider to be essential requirements for
any resulting general-purpose discovery specification:
1. Being able to always discover per-user information with a single GET
(minimizing user inter
Fair enough, carry on. :)
From: Melvin Carvalho [mailto:melvincarva...@gmail.com]
Sent: Thursday, April 19, 2012 9:54 AM
To: Mike Jones
Cc: Murray S. Kucherawy; oauth@ietf.org WG; Apps Discuss
Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)
On 19 April 2012 18:4
On Thu, Apr 19, 2012 at 9:48 AM, Mike Jones wrote:
> There are two criteria that I would consider to be essential requirements
> for any resulting general-purpose discovery specification:
>
> 1. Being able to always discover per-user information with a single GET
> (minimizing user interface late
On 19 April 2012 18:48, Mike Jones wrote:
> There are two criteria that I would consider to be essential requirements
> for any resulting general-purpose discovery specification:
>
> 1. Being able to always discover per-user information with a single GET
> (minimizing user interface latency for
There are two criteria that I would consider to be essential requirements for
any resulting general-purpose discovery specification:
1. Being able to always discover per-user information with a single GET
(minimizing user interface latency for mobile devices, etc.)
2. JSON should be required
I would characterize it as two distinct camps, folks that think WF can be
updated to do what SWD (growing contingent I think) does and folks that are
invested in SWD. I haven't seen any movement between those two camps,
specifically that the SWD folks think WF can in fact solve their problem if
By all means people should correct me if they think I'm wrong about this, but
so far from monitoring the discussion there seems to be general support for
focusing on WebFinger and developing it to meet the needs of those who have
deployed SWD, versus the opposite.
Does anyone want to argue the
A couple months ago I was checking out what was up. The AOL and Yahoo endpoints
no longer worked. The Google one still did.
On Apr 17, 2012, at 3:54 PM, Blaine Cook wrote:
> That's a tricky question - maybe one google can help answer? There are a
> bunch of projects using webfinger, including s
Scope having actual meaning to the client (you usage of 'offline' is what I'm
looking at) is something you can define but is not something currently in the
protocol.
I think it's a simpler picture than you are painting:
1) You might get a hint with the expires_in value for when the token wil
I would find this useful as well.
I've been ramping up on OAuth and have found the lack of standardization of
access tokens very frustrating (structured vs. unstructured, if structured then
what type of structure, etc). Not being able to understand what type of access
tokens are being return
On 03/25/2012 07:51 PM, Aaron Parecki wrote:
> If you have an example of an API that uses structured access tokens, I
> would love some links to documentation or examples. I'm looking for some
> examples of the types of information people put into structured tokens
> for some OAuth 2 tutorials I'm
Some of the use cases I have discussed with people also involve returning SAML
tokens in the response for dealing with some existing systems.
In principal if the RS is authenticated to the AS (perhaps with OAuth) then
the correct response format RS can be provided.
We need to decide what p
Please give me feedback if I got anything wrong, or if you have comments.
https://rnd.feide.no/2012/04/19/best-practice-for-dealing-with-oauth-2-0-token-expiration-at-the-consumer/
Kind regards,
Andreas Åkre Solberg
UNINETT
smime.p7s
Description: S/MIME cryptographic signature
___
35 matches
Mail list logo
