I probably will not be there in person unless the situation improves
dramatically
iPhoneから送信
2020/03/10 10:09、Sascha Preibisch のメール:
I will be there if it is not getting worse. But in any case I am in Vancouver.
Regards,
Sascha
On Mon., Mar. 9, 2020, 11:35 Daniel Fett,
mailto:f...@danielfe
Up until -12 (Feb 13, 2017), it was using merge + JAR precedence if duplicated.
As of -13 (Mar 30, 2017), it was changed that the server does not have to do
the merge, at least for OAuth Authorization request parameters. It says nothing
about other parameters.
As of -14 (Jul 21, 2017), the wordin
+1
野村総合研究所 IT基盤技術戦略室
上席研究員 崎村夏彦
E: n-sakim...@nri.co.jp
T: +81(90)60136276
-
このメールには、本来の宛先の方のみに限定された機密情報が含まれている場合がございます。お心あたりのない場合は、送信者にご連絡のうえ、このメールを削除してくださいますようお願い申し上げます。
PLEASE READ:This e-mail is confidential and intended for the named rec
Sorry to chime in so late as well as I have not been able to follow up all the
mail in the tread, so it may have come up before but just for the sake...
1) Spelling of "OpenID"
"OpenID" is sometimes spelled "OpenID" and sometimes " OpenId".
Please unify to "OpenID" as that is the official way o
Brian,
You are the expert on the particular IANA registries so I probably are missing
something.
I was thinking that registering JWT claims to OAuth registry is sufficient till
seeing Ben’s comment, and I was tracking that it is being done by Mike as part
of the errata process for OIDC Core. H
Agreed.
On the related issue, issue of exporting the access token that a confidential
client got to a public client is there as it was discussed in the Friday’s
Oauth WG meeting. Though I did not make any comment on Friday as we were
running out of time, I think that is a bad idea as the AuthZ
Just refreshed the JPOP draft as it may be pertinent to both DPOP and access
token JWT discussion.
Nat Sakimura
Nomura Research Institute
PLEASE READ：This e-mail is confidential and intended for the named recipient
only. If you are not an intended recipient, please notify the sender and delete
+1
For that matter, explicit typing is good and I am a bit ambivalent on the use
of `sub`.
Also, I need to add the 4th consideration: Although the current privacy
consideration is stating about the encryption, it is in relation to the end
user exposure. In fact, the by-value access token whe
ley
> mailto:ve7...@ve7jtb.com>>:
>
> I am ok with that.
>
> On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt
> mailto:tors...@lodderstedt.net> wrote:
>
> > Am 28.11.2018 um 23:50 schrieb n-sakimura
> > mailto:n-sakim...@nri.co.jp>>:
> >
> >
by
William
We look forward to seeing your feedback.
kind regards,
Torsten.
> Am 29.11.2018 um 15:15 schrieb John Bradley
> mailto:ve7...@ve7jtb.com>>:
>
> I am ok with that.
>
> On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt
> mailto:tors...@lodderstedt.net&
In the case of dynamic client registration for apps, I suppose the
implementations will use other techniques (many of them are proprietary) to
test if the app is the one created by themselves or not. Otherwise, it would
not improve the situation very much.
Nat
Nat Sakimura / n-sakim...@nri.co.
ます。
PLEASE READ :This e-mail is confidential and intended for the named recipient
only.
If you are not an intended recipient, please notify the sender and delete this
e-mail.
差出人: Torsten Lodderstedt
送信日時: 水曜日, 11月 28, 2018 11:38 午後
宛先: n-sakimura
Cc: Dick Hardt
I would support
1) clearly defining Implicit as the flow that returns access token from the
authorization endpoint ( some people confuses implicit as the flow that returns
ID Token in the front channel)
2) Banning the returning of the access token that are not sender constrained
from the autho
v 27, 2018 at 3:50 PM n-sakimura
mailto:n-sakim...@nri.co.jp>> wrote:
Tom,
It is good to hear that you will be there.
I understand John will also be there.
To your question, self-issued ID does not require a (semi-)permanent URL as the
user’s identifier, as it is always “localhost”.
The i
Tom,
It is good to hear that you will be there.
I understand John will also be there.
To your question, self-issued ID does not require a (semi-)permanent URL as the
user’s identifier, as it is always “localhost”.
The identifier is derived as the hash of the public key that was generated by
the
I am not sure about it. There are no confidential implicit grant client that
uses bearer token is correct, but if the token is sender constrained, it can
act as a confidential client.
Think of the case where an OP that is unreacheable directly from the client but
only indirectly through the bro
Good points.
Also, while it may be off-topic, I do see values in implicit flows. In some
cases, such as when the AS is inside the firewall or on a localhost (e.g.,
smartphone), “code flow” is not possible as the client cannot reach the AS
directly. Banning implicit (and thus “token id_token” as
Hmmm. But the Link-header is the generalized discovery method which is pretty
widely used outside of OAuth community with the added benefit of being able to
find things without linking to authentication.
From: OAuth On Behalf Of George Fletcher
Sent: Friday, November 09, 2018 12:12 AM
To: Dick
Just updated a typo that was pointed out.
BTW, the spec has not progressed for a long time. I wonder what can I do to
push it through.
Nat
差出人: internet-dra...@ietf.org
送信日時: 日曜日, 10月 21, 2018 11:17 午後
宛先: Nat Sakimura; John Bradley
件名: New Version Notification fo
Hi David,
Thanks for the comment, and sorry for the delay in my reply.
Doing it with Web Linking [RFC8288] has several advantages.
1. It is standard based ☺ It is just a matter of registering link relations
to the IANA Link Relation Type Registry, and it is quite widely used.
2. No or v
And if it were not obvious, YES ☺
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Dick Hardt
Sent: Friday, July 20, 2018 6:12 AM
To: Rifaat Shekh-Yusef
Cc: oauth
Subject: Re: [OAUTH-WG] Call for adoption for "Distributed OAuth"
I'm supportive. :)
On Thu, Jul 19, 2018 at 4:05 PM, Rifaa
+1
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Friday, July 20, 2018 7:42 AM
To: Rifaat Shekh-Yusef
Cc: oauth
Subject: Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth
2.0"
I support adoption of this document.
On Thu, Jul 19, 2018 at 4:01 P
Torsten,
For the digital signature case, I feel a bit uneasy to sign the hash that was
sent by the client. The signing mechanism, a bank in this case, should display
what is being signed to the user before the user makes a signature. The staging
strategy works here as well. The client sends the
delete
this e-mail.
差出人: Dick Hardt
送信日時: 2018年4月18日 0:40:20
宛先: n-sakimura
CC: Rifaat Shekh-Yusef; oauth
件名: Re: [OAUTH-WG] Call for agenda items
**
本メールはフリーメールから届いています。標的型攻撃メールはフリーメ
ールから届くことがありますので
]
Sent: Wednesday, March 07, 2018 9:22 PM
To: n-sakimura
Cc: Brian Campbell ; oauth
Subject: Re: [OAUTH-WG] Call for agenda items
Nat,
Are you asking for an interim meeting?
We could schedule the Distributed OAuth discussion for the Wednesday meeting;
that will give you guys sometime to discuss
Then let us do it. We need to put all the proposals on the table and strategize
the design.
Perhaps we need a side meeting as well.
nat
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Wednesday, March 07, 2018 1:31 AM
To: Rifaat Shekh-Yusef
Cc: oauth
Subject: Re:
FYI. It is on the week before the IETF 101 London.
Bunch of us are going to be there discussing security aspect of OAuth.
Nat
-Original Message-
From: Roberto Carbone
Sent: Tuesday, March 06, 2018 3:07 AM
Subject: Call for Participation - Third OAuth Security Workshop (OSW 2018)
De
Right. It has been hanging there since July...
Nat
-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Vladimir Dzhuvinov
Sent: Friday, February 09, 2018 5:03 PM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] FW: New Version Notification for
draft-ietf-oauth-jwsreq-1
28 matches
Mail list logo
