Hello.
This looks good to me.
Best regards,
Nat Sakimura
On Wed, 14 Aug 2024 at 06:28, David Dong via RT <
drafts-expert-review-comm...@iana.org> wrote:
> Dear Nat Sakimura, John Bradley, Dick Hardt (cc: oauth WG),
>
> As the designated experts for the OAuth Authorization
h the model without holder, it still lists 8 varieties of
unlinkability. We will have many more in the issuer-holder-verifier model.
We should be aware that there is an operator behind the holder, which can
turn hostile.
Best,
Nat Sakimura
2024年7月23日(火) 13:35 Wayne Chang :
> Yep, TEEs definit
+1
Nat Sakimura
On 2 Oct 2023, 22:11 +0100, Brian Campbell
, wrote:
> I support adoption.
>
> I do think the document would be more appropriately scoped with more focus on
> the status list itself and less so on the JWT/CWT signed representations
> thereof. As such, I'd s
Congratulations!
On Aug 11, 2023 22:19 +0900, Oliver Terbu , wrote:
> Thank you very much! We greatly appreciate your insightful feedback and
> continuous support. As we move forward, we are fully committed to diligently
> refining the document to meet the rigorous technical standards upheld by t
I approve, too.
2023年4月6日(木) 3:34 Mike Jones :
> I also approve this request.
>
>
>
> -- Mike
>
>
>
> *From:* John Bradley
> *Sent:* Wednesday, April 5, 2023 11:13 AM
> *To:* dick.ha...@gmail.com
> *Cc:* drafts-expert-review-comm...
Sorry, "oauth" apparently expanded to oauth list. My sincere apologies.
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
-ietf-oauth-security-topics-22#name-misuse-of-stolen-access-tok
>
> Do you think there is anything missing?
>
> best regards,
> Torsten.
> Am 27. März 2023, 13:48 +0900 schrieb Nat Sakimura :
>
> Hi Rifaat,
>
> Here is my slides on the OAuth 2.0 Proof-of-Possession (P
good information worth making referencable.
Has it been an explicit decision to abandon the document, or is it just the
result of the priority of the editors and this WG shifted away? Is there an
appetite to progress it?
Best,
--
Nat Sakimura
___
OAuth
_
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Thanks for an excellent work.
I am happy that the public key confirmation method in JPOP [1] presented at
IETF OAuth WG in 2017 somewhat morphed into DPOP after 5 years. Also, I was
very happy to see the
[1] https://datatracker.ietf.org/doc/html/draft-sakimura-oauth-jpop-00
I also apologize that
Hi.
Sorry for a late reply.
I am not aware of any IPR related to this draft either.
Best,
Nat Sakimura
2021年3月25日(木) 6:00 Dave Tonge :
> Hi Hannes
>
> I'm not aware of any IPR related to this draft
>
> Thanks
>
> Dave
>
> On Wed, 24 Mar 2021 at 21:46, To
g
> values to the "OAuth Parameters" registry established ..." but they all are
> actually modifying different sub-registries. I suggest naming the
> sub-registries explicitly. I realize the subsection titles have it right,
> but
> this line of repeated prose had me
han you Nat for the quick reply and the fixes
>
>
>
> Regards
>
>
>
> -éric
>
>
>
> *From: *Nat Sakimura
> *Date: *Thursday, 13 August 2020 at 15:43
> *To: *Eric Vyncke
> *Cc: *The IESG , oauth , "
> oauth-cha...@ietf.org" , "
>
_
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
or universally applied?
>
I believe it is for the case require_signed_request_object is true.
>
> Section 12.1
>
>(2) (Translation Process) The client uses the client credential that
> it got to push the request object to the TFP to get the
> "request_uri".
>
> If I understand correctly, the TFP also verifies that the request object
> is consistent with the claims the client is eligible for based on the
> certification step in (1).
>
Yes.
Perhaps I should add text for that.
>
> Section 12.2.2
>
>Therefore, per-user Request Object URI should be avoided.
>
> If I understand correctly, the only possible alternative is to have
> per-request URIs (right?), as coalescing multiple user's requests into a
> single request object URI seems to pose several difficulties. We could
> perhaps make the recommended alternative more clear.
>
>
Right. I will try to come up with a text for this.
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
q-26.txt
Thanks. Will do.
>
>
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
>>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
-line Internet-Drafts
> directories.
> > This draft is a work item of the Web Authorization Protocol WG of the
> IETF.
> >
> > Title : The OAuth 2.0 Authorization Framework: JWT
> Secured Authorization Request (JAR)
> > Authors
Hi,
Sorry for the late reply. I and John were really busy lately partly due to
COVID-19 thing and could not respond in a timely fashion.
I just replied to one of the thread that you posed a question about. Is
that the question you mentioned in this email?
Best,
Nat Sakimura
On Sun, May 31, 2020
go to the attacker's
client. So, the comparison approach does not work.
Best,
Nat Sakimura
On Tue, Jun 2, 2020 at 5:27 PM Denis wrote:
> Hi Benjamin and Aaron,
>
> Note: This is also a reply to Aaron who wrote:
>
> Typically in OAuth it's the authorization server&
find security benefit that balances such
breaking change.
I could add 1) as an optional claim though.
Best,
Nat Sakimura
On Thu, May 7, 2020 at 10:32 PM Brock Allen wrote:
> Perhaps quite late, but a few comments/questions related to this:
>
> 1) When decoded, all the JWT samples are mi
Torsten,
Thanks. I just updated the draft.
Best,
Nat Sakimura
On Sun, May 10, 2020 at 10:26 PM Torsten Lodderstedt wrote:
> I just read over the diff between -21 and -22 and realised the example in
> Section 5.2.2.
>
> https://server.example.com/authorize?
>res
So, I am getting overwhelming approval on getting client_id back.
In the next few days, I will create another draft that has it back.
Best,
Nat Sakimura
On Fri, Mar 13, 2020 at 1:25 AM George Fletcher wrote:
> I'm a +1 for adding client_id back as well
>
> On 3/12/20 11:31 AM,
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
Let us do it then and deprecate ROPC.
There definitely are use-cases that need this pattern around me as well, but we
are using JWT bearer grant instead. Standardizing the behavior is good. I am
fine with new service_account grant type as well, btw.
Nat
2020年2月25日 20:41 +0900、Neil Madden のメール:
client with a different
>> "client_id"./*
>> > >>>>>
>> > >>>> Identifying the client in JAR request_uri requests can be really
>> useful
>> > >>>> so that an AS which requires request_uri registration to prevent
>
it needs to be brought back to the WG last call,
but that is your call.
Best,
Nat Sakimura
On Thu, Jan 30, 2020 at 8:20 AM Benjamin Kaduk wrote:
> Hi Nat,
>
> Now it is my turn to apologize for taking a long time.
>
> I think I see the general direction these changes are going
the URI. It's not clear to me whether that is implied by "not
> perform recursive GET" so it may be worth explicitly spelling that out.
>
> -- Neil
>
>
> On 16 Jan 2020, at 15:47, Nat Sakimura wrote:
>
> Right. We could add a security consideration like that, though
gt; > >>>>>>>>> To be honest, I feel quite bad about the situation with JAR we
> are in
> > >>>>>>>>> now. For some reason I had the impression that OAuth JAR was
> going to be
>
f.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> --
> Vennlig hilsen
>
> Steinar Noem
> Partner Udelt AS
> Systemutvikler
>
> | stei...@udelt.no | h...@udelt.no | +47 955 21 620 | www.udelt.no |
>
ters MUST be
in the request object.
Behaviors towards other parameters that happens to have come together with the
authorization request outside of request object will be treated as non-OAuth
parameters.
Nat Sakimura
Research Fellow, Nomura Research Institute
E: n-sakim...@nri.co.jp
T: +81
at this point, if we can get them to
> agree to the change.
>
> John B.
>
> On Tue, Dec 10, 2019, 11:29 PM Nat Sakimura wrote:
>
>> Correct. The WG supported the precedence approach and even merge just
>> like OIDC as it is very useful from the implementation point
+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
-the-current-text-actually-specifies-the
I am willing to go either way as long as people agree. My slight preference
is to the original approach.
Best,
Nat Sakimura
2019年8月29日(木) 6:56 Brian Campbell :
> FWIW, as best I can remember the change in question came as I result of
> directorat
.)
Did those browsers disappeared? (Hopefully yes but not sure.)
If not, it might be worth adding it.
Best,
Nat Sakimura
-
PLEASE READ:This e-mail is confidential and intended for the named recipient
only. If you are not an intended reci
:
datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
Best,
Nat Sakimura
2019年7月3日(水) 4:21 Benjamin Kaduk via Datatracker :
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-oauth-jwsreq-19: Discuss
>
> When responding, please keep the subject line intact and reply to
As Filip mentioned, I feel that claimed HTTPS URI would help. Further, if that
is used within the dynamic client registration, it could be more secure.
The security assumptions are
1. Phone is not rooted;
2. App Store's vetting of claimed URI is not compromised; etc.
Nat Sakimura
Cha
g list
>>> OAuth@ietf.org
>>>
>>> https://nam06..safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f141a
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
this e
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
to be one of the DEs
> on the JWT claims registry so, in theory, I have some idea what I'm talking
> about here. In theory. And I do have to be upfront at this point and say
> that I will push back on a request for registration of a bunch of
> authorization request parameters into the J
ng by the Client and certifying the request. After the
>certification, the Client, when making an Authorization Request, can
>submit Authorization Request to the Trust Framework Provider to
>obtain the Request Object URI.
>
> side note: In my head the act of certification was the act of making the
> translation to
nt to tackle that
> particular class of scenarios, I think it's fair of us to be explicit about
> it.
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
--
Nat Sakimura (=nat)
Chairman, OpenID
method that
the client was trying to access) while [DPOP] signs over client
created nonce `jti` together with methods, uri, etc.
[JPOP] https://tools.ietf.org/html/draft-sakimura-oauth-jpop-05
[DPOP] https://tools.ietf.org/html/draft-fett-oauth-dpop-02
my 2c.
Cheers,
Nat Sakimura
--
Nat Sakimura
user authorization. So, the protocol needs to be able to start
both ways, I guess.
Cheers,
Nat Sakimura
On Sun, Jul 21, 2019 at 5:28 PM Dick Hardt wrote:
>
> Hey Justin
>
> A few use cases that highlight how the world is different now than it was
> when OAuth 2.0 was devel
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
> Best Regards,
>>> Takahiko Kawasaki
>>>
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
think-oauth-scopes-by-torsten/
Cheers,
Nat Sakimura
On Fri, May 10, 2019 at 10:27 PM George Fletcher
wrote:
>
> One thing to keep in mind with the "Push Request Object" model and the
> concept of a more detailed scope structure, if the specified values are not
> for a sing
+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
rained and access token
>>> injection in
>>> the authorization response is prevented.
>>> —
>>>
>>> Explantation:
>>> - we wanted to have the right balance between a generic definition of
>>> the response types we do not r
; security. (At least that’s the current understanding.)
>
>
>
> I am happy to get corrected.
>
>
>
> Ciao
>
> Hannes
>
>
>
>
>
>
>
> *From:* n-sakimura
> *Sent:* Saturday, December 1, 2018 10:44 AM
> *To:* Hannes Tschofenig ; Aaron Parecki
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>>:
> >
> >
+1
Nat Sakimura / n-sakim...@nri.co.jp / +81-90-6013-6276
このメールには、本来の宛先の方のみに限定された機密情報が含まれている場合がございます。お心あたりのない場合は、誠に申し訳ございませんが、送信者までお知らせ頂き、また受信されたメールは削除してくださいますようお願い申し上げます。
PLEASE READ :This e-mail is confidential and intended for the named recipient
only.
If you are not an intended recipient
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
Inline:
2018年11月29日(木) 0:03 Torsten Lodderstedt :
>
> > Am 28.11.2018 um 23:50 schrieb n-sakimura :
> >
> > That works.
>
> Good!
>
> I just realized this text has an issue with „token“ (only). It would allow
> „token“ to be used if the token would sender co
That works.
In fact, I would further go and say MUST NOT but that probably is too much for
a security consideration.
Best,
Nat
Nat Sakimura / n-sakim...@nri.co.jp / +81-90-6013-6276
このメールには、本来の宛先の方のみに限定された機密情報が含まれている場合がございます。お心あたりのない場合は、誠に申し訳ございませんが、送信者までお知らせ頂き、また受信されたメールは削除してくださいますようお願い申し上げ
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
discovery mechanism that returns [Self-issued Identifier – device type –
claimed URI] triple kind of thing may be useful. (Note, I just came up with it
now and it’s 2 AM here so it may be a bad idea after all.)
Nat Sakimura mailto:n-sakim...@nri.co.jp>>
PLEASE READ :This e-mail is confidenti
is that you cannot reach it. However, It is a
“URI”.
Cheers,
Nat Sakimura mailto:n-sakim...@nri.co.jp>>
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.
From: Openi
ave keys but it is better to
> describe them separately.
> >>>
> >>> John B.
> >>>
> >>> On Tue, Nov 27, 2018, 4:30 PM Torsten Lodderstedt via Openid-specs-ab <
> openid-specs...@lists.openid.net wrote:
> >>> Hi Nat,
> >>>
I am not talking about SPA.
The client is a regular confidential client that is running on a server.
Best,
Nat Sakimura
2018年11月27日(火) 16:55 Jim Manico :
> Nat,
>
> How is proof of possession established in a modern web browser in the
> implicit flow?
>
> My understan
is confidential (based on public key pair),
and uses sender constrained (key-constrained) token such as the one
explained in
https://tools.ietf.org/html/draft-sakimura-oauth-jpop-04#section-5, it is
very useful.
(Key-constrained token is the remaining portion of this draft that did not
get
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
” as well) has this
repercussion and I would not agree to it.
Best,
Nat Sakimura
From: OAuth On Behalf Of Brock Allen
Sent: Friday, November 16, 2018 7:01 AM
To: Torsten Lodderstedt
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00
> It still lacks the abil
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
isclosure by others is strictly prohibited...
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.___
> > OAuth mailing list
> > OAuth@ietf.o
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
embedded resources in the
response. Could you kindly elaborate a little, please?
For the second point, since it was discussed in the WG meeting yesterday, I
will defer to that discussion.
Best,
Nat Sakimura
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of David Waite
Sent: Thursday, July
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
document?
> https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/
>
> Regards,
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
--
Nat Sakimura (=nat)
Chairman, OpenID
,
Nat
Nat Sakimura
このメールには、本来の宛先の方のみに限定された機密情報が含まれている場合がございます。お心あたりのない場合は、送信者にご連絡のうえ、このメールを削除してくださいますようお願い申し上げます。
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
,
Nat
2018年6月22日金曜日、Torsten Lodderstedtさんは書きました:
> Hi Nat,
>
> > Am 21.06.2018 um 10:35 schrieb Nat Sakimura :
> >
> > It depends on the use case but if you are talking about payment etc.,
> putting the transaction details in the scope and sending it over the
> r
>
>> I‘m looking forward for your feedback. Please also indicated whether you
>> think we should flush out a BCP on that topic.
>>
>> kind regards,
>> Torsten.
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
&
(s). Any
> review, use, distribution or disclosure by others is strictly prohibited...
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your com
I support the idea. Adding to it, perhaps we can do an ad-hoc before Montreal
so that we can come up with a combined draft.
Nat Sakimura
--
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
]
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
Lgtm
On Thu, Mar 8, 2018 at 4:58 AM +0900, "Brian Campbell"
wrote:
Looks okay to me too.
I don't think I'll have anywhere close to 20 minutes on
dra
uth:
https://tools.ietf.org/html/draft-sakimura-oauth-meta-08
https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02
https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00
Brian, Hannes,
Are you planning on presenting your documents?
Regards,
Rifaat
On Mon, Mar 5, 2018 at 8
Mitchell (Royal Holloway, University of London)
- Anthony Nadalin (Microsoft)
- Nat Sakimura (Nomura Research Institute)
- Antonio Sanso (Adobe)
- Ralf Sasse (ETH Zurich)
- Joerg Schwenk (Ruhr-Universität Bochum)
- Giada Sciarretta (Security & Trust, Fondazione Bruno Kessler and Univ
I would be interested in hearing that.
Also, as part of "Distributed OAuth", can we do a bit of re-cap on some of
the previous drafts on the similar topic as we discussed in the interim?
i.e., Brian's draft (where is the link now?) and my draft (
draft-sakimura-oauth-meta
<http
with draft-ietf-oauth-jwsreq-15 have gone to
the IESG.
Vladimir
On 21/07/17 16:25, Nat Sakimura wrote:
> Hi
>
> This version hopefully have addressed all the comments that I received during
> IESG review.
> I also added RFC8141 as the reference to URN.
>
> The main differenc
, D., Cremers, C., Meier, S.: Provably Repairing the ISO/IEC 9798
Standard for Entity Authentication. Journal of Computer Security - Security
and Trust Principles archive Volume 21 Issue 6, 817-846 (2013)
Best,
---
Nat Sakimura
On Thu, Jan 25, 2018 at 11:28 PM Brian Campbell
wrote:
> Hi
rom:
Date: Wed, Nov 15, 2017 at 5:30 PM
Subject: New Version Notification for draft-sakimura-oauth-meta-08.txt
To: Nov Matake , Sascha Preibisch ,
Nat Sakimura , Sascha Preibisch <
sascha.preibi...@gmail.com>
A new version of I-D, draft-sakimura-oauth-meta-08.txt
has been successfully
of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> ___
> OAuth mailing list
> OAuth@ietf.org
&
.
Am I clear enough?
Nat
On Fri, Oct 13, 2017 at 2:11 AM William Denniss wrote:
> Hi Nat,
>
> Thanks for reviewing the draft!
>
> On Thu, Oct 12, 2017 at 9:57 AM, Nat Sakimura wrote:
>
>> Thanks to the authors for coming up with this document.
>> The scenario is ve
ge that displays the verification URI and the user code.
The client does nothing but a regular PKCE. This kind of use case is out of
scope for this document, is it correct?
Cheers,
Nat Sakimura
--
Nat Sakimura
Chairman of the Board, OpenID Foundation
__
+1 Sent from Astro for Android On 2017-08-29 at 4:33 AM, Torsten
wrote: +1 for removing tls_client_auth_root Am 28.08.2017 um 20:24
schrieb John Bradley : Having discussed it with
Brian, I agree that removing “tls_client_auth_root” is the way to go.
It would be hard to implement in some cases, and
security
consideration.
Best,
Nat Sakimura
--
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.
> -Original Message-
> From: internet-dra...@ie
Thanks Alexey, and sorry for taking this long.
I will fix the nits about URN ASAP.
Best,
Nat
--
このメールは、本来の宛先の方のみに限定された機密情報が含まれてい
る場合がございます。お心あたりのない場合は、送信者にご連絡のうえ、
このメールを削除して下さいますようお願い申し上げます。
PLEASE READ :This e-mail is confidential and intended for the
named recipient only. If you are not an
Type and (possibly) Transfer-Encoding header fields.
>> Without these it doesn't look syntactically correct.
>>
>>
>>
>>
>>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
CWTs. We
> would like to learn more about your usage.
>
> Ciao
> Hannes & Kepeng
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
--
Nat Sakimura
Chairman of the Board, O
s. Authors of accepted papers will have the option to
> revise their papers before they are put online.
>
>
> IPR Policy
>
> The workshop will have no expectation of IPR disclosure or licensing
> related to its submissions. Authors are responsible for obtaining
> appropriate
+1 for adoption
On Apr 21, 2017 9:32 PM, "Dave Tonge" wrote:
> I support adoption of draft-campbell-oauth-mtls
>
> As previously mentioned this spec will be very useful for Europe where
> there is legislation requiring the use of certificate-based authentication
> and many financial groups and i
n the current proposal a client could put the required parameters both
places and the same request would work on servers supporting both the
Connect and OAuth versions.
John B.
Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows
10
*From: *Torsten Lodderstedt
; Ciao
> > Hannes
> >
> >
> >
> > ___
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
> ___
> OAuth mailing list
&
4:44 PM
>To: Mike Jones
>Cc: Nat Sakimura ; IETF oauth WG
>Subject: RE: [OAUTH-WG] FW: I-D Action: draft-ietf-oauth-jwsreq-13.txt
>
>The intent of the change is to only allow the paramaters to be in the
>signed object if a signed object is used.
>
>This requires State
ed version available at:
> https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-07
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-exchange-07
>
>
> Please note
FYI
-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
Sent: Monday, March 27, 2017 2:40 PM
To: Nat Sakimura ; Kepeng Li
; John Bradley
Subject: New Version Notification for draft-sakimura-oauth-jpop-04.txt
A new version of I-D, draft-sakimura-oauth
so.) Pull request would be nice, too, but we are going to do a bit of
> surgery on the spec as of now, so it might be wise to wait till after that
> to avoid conflicts.
>
> Also, it is not yet a WG document so please support it become one.
>
> Best,
>
> Nat Sakimura
>
1 - 100 of 498 matches
Mail list logo
