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
dd.
I might come up with some additional ones by the deadline, but for now, the
above is what I have.
Cheers,
Nat Sakimura
On Mon, Mar 28, 2022 at 9:01 PM Rifaat Shekh-Yusef
wrote:
> All,
>
> As discussed during the IETF meeting in *Vienna* last week, this is a *WG
> Last Call *
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,
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 |
>
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
-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
:
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
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
> 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
>>> >In order to avoid these issues, Clients SHOULD NOT use the implicit
>>> >grant. Furthermore, clients SHOULD only use other response types
>>> causing the authorization server to
>>> >issue an access token in the authorization response, i
gt;grant. Furthermore, clients SHOULD only use other response types
> causing the authorization server to
> >issue an access token in the authorization response, if the
> particular response type detects access token
> >injection and the issued access tokens are sender-co
nse types are expanded.
>
> >
> > In fact, I would further go and say MUST NOT but that probably is too
> much for a security consideration.
> >
>
> Mike suggested to go with a SHOULD NOT to get the message out but give
> implementors time to move/change.
As W
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
incorporated in the MTLS draft. )
In fact it is the only viable method for Self-Issued OpenID Provider.
So, the text is generally good but it needs to be constrained like “Unless
the client is confidential and the access token issued is key constrained,
“
Best,
Nat Sakimura
2018年11月27日(火) 16:01
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
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
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
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
plan
>>
>> is to run a call for adoption once we are allowed to add a new
>> milestone
>>
>> to our charter.
>>
>>
>>
>> - Distributed OAuth
>>
>> # draft-hardt-oauth-distributed-00
>>
>>
>>
>> Remark: We had a virtual in
, 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
>
y 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
On Wed, Mar 22, 2017 at 5:15 AM Denis wrote:
> Hi Nat,
>
>
> I have several comments on draft-sakimura-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
Chairman of the Board, OpenID Foundation
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
be great if it can be considered in the WG.
Best,
Nat Sakimura
On Tue, Mar 21, 2017 at 10:28 PM Antonio Sanso wrote:
hi Torsten,
good one. I personally I am looking forward to see this particular document
find its way.
IMHO this is something much needed.
regards
antonio
On Mar 21, 2017, at
be pretty large and I do not want to
> double base64url encode.
> - perhaps change ts to string to accommodate nonce like string.
>
> Essentially, what I want to do is not the http signing but just the pop
> based client authentication, which is very simple.
>
> While I was wr
here: http://bit.ly/oauth-jpop
Financial API uses cases needs something like that.
(Another possibility is a sender confirmation.)
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
es you are relying on the client authentication or PKCE to bind
> to the correct client.
>
> They are more or less equivalent. I prefer the private key to never
> leave the device personally.
>
> This has been debated several times.
>
> John B.
>
> On Mar 3, 2017 12:
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@ie
_
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
--
Nat Sakimura
Chairman of the Board, OpenID Foundation
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
ot; and
MUST verify that it exactly matches with the URI of the endpoint that it
received the response.
Cheers,
Nat Sakimura
On Wed, Mar 1, 2017 at 5:51 AM Brian Campbell
wrote:
> -07 LGTM
>
> On Feb 20, 2017 2:53 AM, "Hannes Tschofenig"
> wrote:
>
> Hi all,
>
&g
Hi OAuthers:
I was reading draft-ietf-oauth-token-binding-01 this afternoon and thought
that examples for each subsection of 2 and 3 would be helpful.
Is it possible/sensible to add them?
Best,
Nat
--
PLEASE READ :This e-mail is confidential and intended for the
named recipie
eference to 29100, I meant to write a fuller write
up using it as it would be useful for the orgaanizations implementing ISMS.
(Privacy extensions to ISMS are written based on 29100).
But I did not. I may just drop the reference as well since collection
minimization and disclos
t;> *When the Client is being granted access to a protected resource
>> containing personal data, the Client SHOULD limit the collection of
>> personal data to that which is within the bounds of applicable lawand
>> strictly necessary for the specified purpose(s).*
>>
>> The *presentation* of personal data should be limited whether or not
>> the protected resource contains personal data.
>>
> It is proposed to change this text into:
>>
>>
>>
>>
>> * When the Client requests an access to a protected resource, the
>> ClientSHOULD limit the presentation of personal data to that which is
>> withinthe bounds of applicable law and strictly necessary for the
>> specifiedpurpose(s).*
>>
> Reject.
> You are not getting what OAuth does. The party that holds personal data is
> the authorization server / resource.
> It is not the client. The client is the party who is getting those
> "resources" which may contain personal data.
> Yes, the client can provide some personal data to the resource depending
> on what that resource endpoint is, but that is out of scope for OAuth.
> As far as OAuth is concerned, what is being sent from the client to the
> resource is the access token.
>
>
> The dispute is whether the protected resource contains or not personal
> data.
> The data contained by the protected resource may well be public data
> (or/and personal data).
> It does not need to be only "personal data".
>
>
>
> Hence, I maintain my comment.
>
> I do not understand your comment now. Your previous proposeal seems to be
unrelated to the above comment.
>
> 11. Section 11.2.1 states:
>>
>> 11.2.1. Request Disclosure
>>
>>This specification allows extension parameters.
>>
>> It would be useful to name either all of them or some of them. RFC 6749
>> is not crystal clear about this.
>>
> Noted.
> RFC6749 only defines how to define extension parameters.
> This specification draws from OpenID Connect for some examples of
> extension parameters such as nonce.
> See section 4 for example.
>
>
> See my earlier comments where client_id and nonce shall be mandatory.
>
>
client_id is mandatory in RFC6749. Nonce is not defined in RFC6749 and
hence out of scope for this specification.
> Denis
>
[snip]
--
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
> > This draft is a work item of the Web Authorization Protocol of the IETF.
> >
> > Title : The OAuth 2.0 Authorization Framework: JWT
> Secured Authorization Request (JAR)
> > Authors : Nat Sakimura
> >
t; _______
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
--
Nat Sakimura
Chairman of the Board, OpenID Foundation
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
ed so that the integrity, source
>authentication and confidentiality property of the Authorization
>Request is attained. The request can be sent by value or by
>reference.
>
>
>
>
> The file can be obtained
> viahttps://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/
>
> IESG discussion can be tracked
> viahttps://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
> The document contains these normative downward references.
> See RFC 3967 for additional information:
> rfc6234: US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)
> (Informational - IETF stream)
> rfc6819: OAuth 2.0 Threat Model and Security Considerations
> (Informational - IETF stream)
> rfc6973: Privacy Considerations for Internet Protocols (Informational -
> IAB stream)
> Note that some of these references may already be listed in the acceptable
> Downref Registry.
>
>
> ___
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
--
Nat Sakimura
Chairman of the Board, OpenID Foundation
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
.org/mailman/listinfo/oauth
>
>
>
>
> _______
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
> --
> Jim Manico
> Manicode Securityhttps://www.manicode.com
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
--
Nat Sakimura
Chairman of the Board, OpenID Foundation
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
ase let me know if there are other changes needed.
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: inter
ail.
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
Sent: Wednesday, January 4, 2017 4:45 AM
To: Nat Sakimura
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-jwsreq
Snip
On Jan 3, 2017, at 2:36 PM, Nat Sakimura mailto:sakim...@gmail.com> > wro
or amending your proposal after several private
exchanges.)
>
>
> 4) On page 14, in section 6.3, the text states:
>
> the Authorization Server then validates the request as specified in
> OAuth 2.0 [RFC6749].
>
> This is rather vague, since no specific section from RFC
et.org/Nat/oauth-jwsreq/commits/9030e1be5cac
> Thank you.
> --
>
> Best regards,
> Kathleen
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
--
Nat Sakimura
Chairman of the Board, OpenID Foundation
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
of a secure element simply protecting the confidentiality and the
> integrity of some secret key or private key
> will be ineffective
>
> to counter the Alice and Bob collusion attack. Additional properties will
> be required for the secure element
> (i.e. some physical device with
o Alice so that she can use it.
>
> *draft-ietf-oauth-token-exchange-06 **should take into consideration the
> ABC attack.*
>
> The threat related to the ABC attack should be identified in the security
> considerations section
> and the core of the document should attempt to identify one or more way
nks, Nat.
>
>
>
> Scott
>
>
>
> *From:* Nat Sakimura [mailto:sakim...@gmail.com]
> *Sent:* Tuesday, September 27, 2016 10:03 AM
> *To:* Hollenbeck, Scott; Justin Richer; oauth@ietf.org
>
>
> *Subject:* Re: [OAUTH-WG] Identity Provider Interop Testing?
>
>
ight people without having to deal with the overhead
> of getting an IPR Agreement in place to gain posting privileges.
>
> Scott
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
--
Nat Sakim
Confirmed.
BTW, I was waiting for your confirmation about the draft title change as
discussed in the list.
Shall I just push it?
2016/09/19 午後7:07 "Hannes Tschofenig" :
> Hi Nat, Hi John,
>
> I am working on the shepherd writeup for the JAR document:
> https://tools.ietf.org/html/draft-ietf-oau
;
>
>
> ___
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
> --
> Vladimir Dzhuvinov
>
> ___
> OAuth mailing list
> OAuth@ietf.org
>
The token exchange endpoint at ASf has no ability to issue a usable access
token in this case. The client has to talk to the token exchange endpoint
at ASr to get an access token to be used at the RS, IMHO.
2016年8月5日(金) 20:20 Sergey Beryozkin :
> Hi Nat
> On 05/08/16 11:16, Nat Sakimura
is used instead then it is the
> case
> >>>>>> of the client impersonating the user. And refer to the STS for the
> REST
> >>>>>> of Us draft (I have a separate series of question on that draft).
> I'm
> >>>>>> saying t
1 - 100 of 468 matches
Mail list logo
