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
.
>
> Sent from my iPhone
>
>
>
> On Apr 5, 2023, at 1:59 PM, Dick Hardt wrote:
>
>
>
> I approve this request.
>
>
>
> On Wed, Apr 5, 2023 at 8:47 AM David Dong via RT <
> drafts-expert-review-comm...@iana.org> wrote:
>
> Dear Michael,
Sorry, "oauth" apparently expanded to oauth list. My sincere apologies.
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
ver Interaction
- Resource and Authorization Server Interaction (Token Introspection)
Some of them are not covered by Security BCP, but not all. That is only
natural as there are no corresponding specs.
>From what I can see, they serve very different purposes and target
audiences.
Best,
Nat
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" , "
>
Dear Robert,
Thanks for the comment.
Internet Explorer limitation is interesting from the historical perspective
but can probably now safely removed as well.
We may want to put an example such as a Mobile App spawning external
browser to make an authorization request instead.
Cheers,
Nat
On
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
equest to
https://bitbucket.org/Nat/oauth-jwsreq/src/default/draft-ietf-oauth-jwsreq.xml
by
the way.
By "recursive" I exactly meant that AS should not follow redirect blindly.
I did not state that AS MUST NOT follow redirect as I feared that there
could be an implementation or middleware that imple
;>
> > >>>>>>>>> Our DDoS attack mitigation (for OIDC request_uri) also relies
> on the
> > >>>>>>>>> presence of client_id as top-level parameter, together with
> requiring
> > >>>>>>>>&g
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
Correct. The WG supported the precedence approach and even merge just like
OIDC as it is very useful from the implementation point of view and helps
with a bunch of deployment patter.
The push back came in from the Ben Campbell’s DISCUSS.
See
https://bitbucket.org/Nat/oauth-jwsreq/issues/70/bc
:
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
ry is
deterministic and therefore simple.
On Fri, Jul 26, 2019 at 4:47 PM Brian Campbell
wrote:
> Nat, you suggest that the "simplest solution probably is to register the
> authorization request parameters to the JWT Claims registry." However, as
> I've attempted to articulate seve
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
.
2) ROPC is a good flow for migrating a password storing app to OAuth
as depicted in https://youtu.be/zuVuhl_Axbs . So, completely denying
it is a touch too much. It should very narrowly constrain its
applicability.
Cheers,
Nat
On Wed, Jul 24, 2019 at 11:33 AM Vittorio Bertocci
wrote:
>
>
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
y". I feel that just saying as
suggested by Brian safer. My 2c.
Nat
On Sat, Dec 1, 2018 at 7:24 AM Brian Campbell wrote:
> Kind of, yes. I guess so. I think. It's just semantics. But yeah. Key
> constrained might be more appropriate. But the Security Topics document
&g
sender constraint to MTLS in the WG,
e.g., when the network after TLS has been terminated cannot be entirely
trusted.
Best,
Nat
On Mon, Dec 3, 2018 at 6:39 PM Hannes Tschofenig
wrote:
> (chair hat off)
>
>
>
> Hi Nat,
>
>
>
> Section 3.8.1.2
> <https://too
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
te:
> I still don’t understand why the use case must be solved using a flow
> issuing something in the front channel.
>
> I would also like to take a closer look. Can you or Nat provide pointers
> to existing implementations?
>
> > Am 27.11.2018 um 21:36 schrieb John Bradley :
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
to the staging endpoint as it is a
server to server thing;
2) You can do the "auth" and then later "capture" after shipping the
product strategy using the access token the client has obtained;
3) The content of the transaction is not exposed via URL nor referrers.
Best,
Nat
On
(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
s://tools.ietf.org/id/draft-sakimura-oauth-meta-08.txt>)?
Best,
Nat
On Tue, Mar 6, 2018 at 3:30 AM William Denniss wrote:
> Hannes & Rifaat,
>
> I would like the opportunity to present on OAuth 2.0 Incremental
> Authorization (draft-wdenniss-oauth-incremental-auth) [an update
, 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
I just revved the expired and archived draft so that it will be easier for
discussion around draft-hardt-oauth-distributed .
This is the draft I mentioned during the meeting. Previous versions had
JSON response as "_links" as well.
Best,
Nat
-- Forwarded message -
F
will provide
a uniform viewpoint to each attack, so it may be worthwhile to do.
Nat
[BCM] Basin, 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
.
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
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
mitigate it.
Nat
On Tue, Jun 13, 2017 at 3:19 AM Hannes Tschofenig
wrote:
> Hi all,
>
> RFC 7800 defines how to communicate Proof of Possession (PoP) keys for
> JSON Web Tokens (JWTs) [RFC 7519]. The CBOR Web Token (CWT)
> draft-ietf-ace-cbor-web-token spec defines the CBOR/COSE equi
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
Thanks Brian for spotting these. I will make the corrections in -14.
Best,
Nat
On Fri, Mar 31, 2017 at 10:40 PM Brian Campbell
wrote:
and a typo - "If thie location is" should say "If this location is"
On Fri, Mar 31, 2017 at 8:37 AM, Brian Campbell
wrote:
BTW, the
uesday, March 7, 2017 10:02 AM
> To: Hannes Tschofenig
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] OAuth 2.0 Authorization Server Metadata: IPR
> Confirmation
>
> I have no IPR disclosures to make.
>
> John B.
> > On Mar 7, 2017, at 2:50 PM, Hannes Tschofenig
>
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
is going with this
token is not an issue here.
The protected resource and the authorization server belongs to the same
administrative domain.
Best,
Nat
On Mon, Mar 27, 2017 at 3:46 AM Denis wrote:
> Hi Nat,
>
> At present, I do not support the adoption of this document as a WG
> do
Hi Denis,
Thanks.
Is it possible to file these separately at
https://bitbucket.org/Nat/oauth-rjwtprof/issues?status=new&status=open so
that each issue can be closed separately? (You need to login to bitbucket
to do so.) Pull request would be nice, too, but we are going to do a bit of
surger
early
on in the week will facilitate the discussion during the week as it will be
pretty much the first time for the WG to get exposed to it.
Best,
Nat
On Fri, Mar 24, 2017, 4:34 AM Torsten Lodderstedt
wrote:
> Hi Hannes,
>
> I had asked for 5 minutes on Monday (because I want
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
container
format.)
And, I have not yet posted oauth-jpop as an I-D :-) It is still in my repo
only and it has got more things to be done before it can be posted.
Hopefully, I can add more text and post it by Friday this week to make the
deadline for the next IETF.
Best,
Nat
On Tue, Mar 7, 2017 at 7
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
require keys to be generated by the client.
>From editorial point of view, I would appreciate if you can put
sub-headings to each topics dealt in 7. Security Considerations.
Best,
Nat
On Fri, Mar 3, 2017 at 1:07 PM John Bradley wrote:
> The private key is encrypted to the client.
server has everything needed to
impersonate the client, which may not be desirable.
Is it not simpler and better to REQUIRE the `key` parameter?
Nat
On Sat, Feb 25, 2017 at 8:51 AM John Bradley wrote:
> The European banks are interested in mutual TLS for server to server
> connections as part o
_
> 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
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
Hi Denis,
Thought John's response went to you as well but apparently not.
My replies inline:
On Fri, Feb 10, 2017 at 6:15 AM, Denis wrote:
> Hi Nat,
>
> My replies to your proposed disposition of comments are embedded in the
> text.
>
[snip]
> Section 4 states:
>&
shortly.
Nat
--
このメールは、本来の宛先の方のみに限定された機密情報が含まれてい
る場合がございます。お心あたりのない場合は、送信者にご連絡のうえ、
このメールを削除して下さいますようお願い申し上げます。
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
Thanks Joel,
-11 only contains the fixes to the comments received by Jan. 17. I am now
applying all the edits needed for the comments received after that.
The next version will fix the problem you have pointed out.
Best,
Nat
On Fri, Feb 3, 2017 at 8:03 AM Joel Halpern wrote:
> Reviewer: J
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
Yes, indeed. And when I wrote "acceptable", I meant "in principle", not
verbatim ;-)
Nat
--
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-m
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
commendations for Secure Use of
>Transport Layer Security (TLS) and Datagram Transport Layer Security
>(DTLS) [RFC7525].
>
> Not a major change and just editorial, so take it or leave it.
>
Accepted as presented in my personal copy.
See: https://bitbucket.org/Nat/oauth-j
odka every time so the risk stays the
same as pre-attack.
Mitigation 2: If the AS provides only very short lived access/refresh
token, then Alice has to get Bob act for her every time and so it becomes
the same as Bob buying vodka for Alice every time so the risk stays the
same as pre-attack.
Best
work.
- For something like Age verification, recognizing such attacks, it
probably is a bad practice to rely on refresh/access token. The service
should do more active check, e.g., through OpenID Connect.
Best,
Nat
On Tue, Nov 8, 2016 at 2:54 AM Denis wrote:
> Section 5 of &qu
Just as a side note: we are constructing the RP testing suite right now.
Perhaps you might want to become a beta tester as well. For more info,
please contact Mike Jones, who is CC'ed, for the detail.
Best,
Nat
On Tue, Sep 27, 2016 at 11:22 PM Hollenbeck, Scott
wrote:
> Tha
Interop Group:
https://groups.google.com/forum/#!forum/openid-connect-interop
Cheers,
Nat
On Mon, Sep 19, 2016 at 11:37 PM Hollenbeck, Scott
wrote:
> > -Original Message-
> > From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Justin Richer
> > Sent: Monday, Septe
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.ie
tor needs to support the notion of the group identifier and
allowed processing on them (combined, it sometimes is called `scope`) as
well.
Then, there is a problem of authorization request / response not tamper
protected nor source authenticated. To be really useful, it also has to be
addressed.
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
pattern is perfectly
legitimate as long as the RS is also in the audience.
Best,
Nat
2016年8月5日(金) 5:58 John Bradley :
> The token exchange spec allows for the token issued to have claims about
> the subject of the input token. This is what we generally think about as
> impersonation.
> T
1 - 100 of 477 matches
Mail list logo
