indifferent :)
On 2011-02-08, at 3:04 PM, Mike Jones wrote:
> Given that people are clearly voting to change the bearer token scheme name,
> but that there is also significant discussion asking for “OAuth2” to be part
> of the name, I’d like to settle the matter by vote on the list. Please vot
-1
Many sites are using OAuth (or something like it) in native apps now.
One of the objectives of having a standard is to bring best practices and
standardization to how to solve a problem rather than "a million freakin unique
snowflakes" where developers have to learn and code each mechanism
ick. But in the absence of any
> specific solution or recommendation from the WG regarding native apps,
> I am simply asking that the somewhat misleading text be removed from
> the framework spec.
>
> On Sun, Mar 6, 2011 at 3:12 PM, Dick Hardt wrote:
>> -1
>>
>>
I'm fine with any of the options Eran proposed.
The document has become much more Eran's than anyone else's which leads me to
lean towards just listing Eran as the editor.
-- Dick
On 2011-03-27, at 1:43 AM, Peter Saint-Andre wrote:
>
>
> On 3/27/11 12:36 AM, Eran Hammer-Lahav wrote:
>> The s
On 2011-03-29, at 4:40 PM, Eran Hammer-Lahav wrote:
> To clarify, I am not opposed to mandating TLS on the callback, just that if
> we do, we can’t ship the protocol the way it is without coming up with some
> other alternative that does not require TLS deployment on the client side.
> OAuth 1
back (via redirection). Every developer will need to get a
> cert and deploy an HTTPS endpoint.
>
> That’s has never been discussed.
>
> EHL
>
> From: Dick Hardt [mailto:dick.ha...@gmail.com]
> Sent: Tuesday, March 29, 2011 9:02 PM
> To: Eran Hammer-Lahav
> Cc: WG
>
would argue is VERY concerned about risks of impersonation and real financial
> loss.
>
> Phil
> phil.h...@oracle.com
>
>
>
>
> On 2011-03-30, at 8:19 AM, Dick Hardt wrote:
>
>> Thanks for pointing out my misunderstanding. I was thinking client in the
>>
On 2011-03-31, at 7:32 AM, Skylar Woodward wrote:
> A requirement for TLS on the callback would make OAuth prohibitive for many
> of our developers. The developers are usually volunteers and they are already
> donating their own resources to help a non-profit (from which US law mandates
> the
As has been pointed out in the discussions, if a website does not employe TLS
on connections on other connections, having TLS on the redirect does not add
security.
Depending on the resource grant being given, the nature of the website, not
running TLS may be an acceptable security tradeoff. N
I also am confused by change like this when we are at WGLC.
I was under the impression that once the WG finished last call, the IETF
security mafia experts would be reviewing the spec -- so it is unclear what
advantage this has for getting the spec finished.
On 2011-04-02, at 12:58 PM, David Re
On 2011-04-02, at 11:13 AM, Francisco Corella wrote:
>
> > Another example I mentioned earlier is when the client does
> > not expose the protected resources back to the bearer of the
> > code. For example, a Twitter application sending you emails
> > when someone stops following you. Since all i
On 2011-04-19, at 10:51 AM, David Recordon wrote:
> I think requests like this and the following discussions have scared
> away many of the original voices behind OAuth 2.0. As Eran said, the
> goal was never to create a new framework but standardize interoperable
> best practices that the indust
On 2011-04-19, at 11:41 AM, Eran Hammer-Lahav wrote:
>
>
>> -Original Message-----
>> From: Dick Hardt [mailto:dick.ha...@gmail.com]
>> Sent: Tuesday, April 19, 2011 11:37 AM
>
>> The feature described was in OAuth-WRAP which was a basis for OAuth 2.0
.org/html/draft-ietf-oauth-v2-15#section-4.5
> [2] http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-03
>
>
>> -Original Message-
>> From: Dick Hardt [mailto:dick.ha...@gmail.com]
>> Sent: Tuesday, April 19, 2011 11:59 AM
>> To: Eran Hammer
ons is to add something like 4.4.3 to 4.5? That sounds like a
> good idea.
>
> Would that resolve the potential confusion here?
>
> EHL
>
> From: Dick Hardt
> Date: Tue, 19 Apr 2011 13:25:15 -0700
> To: Eran Hammer-lahav
> Cc: "record...@gmail.com"
I find the break down between authentication, authorization and delegation
referenced in the agenda confusing. I know what each of the words mean, but not
having been part of the early IETF OAuth conversation, I'm confused with the
breakdown as described in the agenda.
Would it be appropriate t
On 2010-02-02, at 2:08 PM, Peter Saint-Andre wrote:
> On 1/28/10 11:35 PM, David Recordon wrote:
>> I have a pretty strong preference of sticking with OAuth 1.0 terminology
>> as much as possible.
>
> Agreed.
The term "server" in OAuth 1.0 does not differentiate between the Authorization
Server
Hi Eran
I think it is a little early in our phone discussions to get into technical
details. The next step according to the last call was to gather and review use
cases. Without rough consensus on what problem we are solving, your points
below (which all do need to be discussed at some point) i
m: Anthony Nadalin [mailto:tony...@microsoft.com]
>> Sent: Wednesday, February 03, 2010 9:02 AM
>> To: Eran Hammer-Lahav; Dick Hardt
>> Cc: OAuth WG
>> Subject: RE: [OAUTH-WG] proposed agenda for second interim meeting
>>
>> I would tend to agree with Dick based
cuss technical issues and
> that is what this second call is about. Unless the chairs decide to change it.
>
> EHL
>
>> -Original Message-
>> From: Dick Hardt [mailto:dick.ha...@gmail.com]
>> Sent: Wednesday, February 03, 2010 9:43 AM
>> To: Eran Ham
On 2010-02-03, at 11:19 AM, Eran Hammer-Lahav wrote:
> I did not mean my first reply to you to be abrasive or confrontational,
> despite being told that my work on the drafts is a waste of time ("moving
> around deck chairs on the Titanic").
I and many others appreciate your work. That was not
On 2010-02-03, at 11:21 AM, Eran Hammer-Lahav wrote:
>> -Original Message-
>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
>> Of Eran Hammer-Lahav
>> Sent: Wednesday, February 03, 2010 11:19 AM
>> To: Dick Hardt
>> Cc: OAuth WG
On 2010-02-03, at 12:01 PM, Peter Saint-Andre wrote:
>
>
> On 2/3/10 12:46 PM, Dick Hardt wrote:
>
>> Wanting to discuss technical details when there does not seem to be
>> consensus on the problem we are solving was my Titanic reference.
>
> Remember, these i
On 2010-02-03, at 10:54 AM, Eve Maler wrote:
>
> - There is a conceptual similarity between the UMA and WRAP entities, but our
> analysis so far shows it to be shallow in spots. For example, WRAP's
> "protected resource" maps fairly well to an UMA "host" (which may host any
> number of prote
On 2010-02-04, at 10:47 AM, Peter Saint-Andre wrote:
>
>
> On 2/3/10 11:55 AM, Dick Hardt wrote:
>> I recall from the call that Peter did ask if there was consensus on
>> the approach of gathering use cases. There seemed consensus that the
>> WG might not fully unde
How about using draft-hardt-oauth-wrap and adding a section for how the Client
can sign?
-- Dick
On 2010-02-04, at 11:28 PM, Eran Hammer-Lahav wrote:
> On the call today I clarified what is going on with all the different drafts.
> In brief:
>
> draft-hammer-oauth - documentation of the OAuth
On Sat, Sep 21, 2024 at 4:28 PM Daniel Fett wrote:
> Hi Dick,
> Am 21.09.24 um 06:41 schrieb Dick Hardt:
>
> Hey Brian, Kristina, Daniel
>
> I appreciate you have been working on this for a while, and this feedback
> is last minute, and people have already working code that
I've rewritten the introduction. Take what you want from it!
I dropped language about how the mechanism is general purpose and is easy
to use. This is not a patent application!
I submitted as a PR as requested, and am including the text below so it is
more accessible to the list.
# Introd
Hey Brian, Kristina, Daniel
I appreciate you have been working on this for a while, and this feedback
is last minute, and people have already working code that works with it --
so this is unlikely to be welcome feedback -- but in the spirit of wanting
what is best long term, here it is.
*Token Se
Is it really going to be practical to batch issue claims, and have the
holder randomly choose between them on presentation?
As an implementer, what is the right number of claims to be in a batch?
This section of the draft reads as a hack to add a new capability
(unlinkability) to a mechanism that
ts. This was neither invented by us, nor is it unreasonable to ask
> implementers to do it. Protocols such as OpenID4VCI support it.
>
> -Daniel
> Am 21.09.24 um 06:42 schrieb Dick Hardt:
>
> Is it really going to be practical to batch issue claims, and have the
> holder randomly choos
to provide clarification on my feedback and engage in productive
discussion -- I'm not interested in trying to convince any of you to change
anything.
/Dick
On Sat, Sep 21, 2024 at 6:15 PM Dick Hardt wrote:
>
>
> On Sat, Sep 21, 2024 at 4:28 PM Daniel Fett wrote:
>
>>
D-JWT
> for the Other use case, which would use the “typ” value “other+sd-jwt” –
> meeting the goal of explicit typing.
>
>
>
> -- Mike
>
>
>
> *From:* Dick Hardt
> *Sent:* Saturday, September 21, 2024 9:16 AM
> *To:* Daniel Fett
> *Cc:* oau
ering
> the names _sd and _sd_alg as other claims about claims.
>
>
>
> -- Mike
>
>
>
> *From:* Dick Hardt
> *Sent:* Saturday, September 21, 2024 9:16 AM
> *To:* Daniel Fett
> *Cc:* oauth
owever, an issue raised at this stage is not
> necessarily a new revelation, nor does it automatically warrant higher
> priority than it had before.
>
>
>
>
> On Sun, Sep 22, 2024 at 8:12 AM Dick Hardt wrote:
>
>> I wrote this feedback right after I had written the re
there are ways other than batch issuance to achieve
> verifier-verifier unlinkability.
>
> Best,
> Kristina
>
>
> On Sat, Sep 21, 2024 at 5:56 PM Dick Hardt wrote:
>
>> I understand it has become the accepted approach. It still comes across
>> as a hack, and ther
gt; "example" is replaced by the identifier for the specific kind of JWT.
>>>>
>>>>
>>>>
>>>> SD-JWT is doing the same thing, recommending the use of the media type
>>>> suffix “+sd-jwt”.
>>>>
>>>>
>>>>
>>&
oc/rfc8725/
>
> [4] SD-JWT architecture feedback received several days after the close of
> WGLC
> https://mailarchive.ietf.org/arch/msg/oauth/412IiUprR9YbXNfEGfSXVVx_pzk/
>
> [5] Media Type Registration in the draft
>
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth
st partially) processed to get to the value of that
> header to say how to process the thing that's already being processed will
> not help make things less confusing.
>
>
>
> On Tue, Sep 24, 2024 at 11:18 AM Dick Hardt wrote:
>
>> Sorry Brian, I'll try again.
&
re clearly that the details of
> batch issuance are defined elsewhere and what kind of details need to be
> defined in that document.
>
> Best,
> Kristina
>
>
>
> On Tue, Sep 24, 2024 at 9:22 AM Dick Hardt wrote:
>
>> My feedback is that the current language on
ng has become the default approach to
>> circumvent the inherent limitations of salted-hash-based credentials
>> formats. This was neither invented by us, nor is it unreasonable to ask
>> implementers to do it. Protocols such as OpenID4VCI support it.
>>
>> -Daniel
>>
501 - 541 of 541 matches
Mail list logo
