profile
viewpoint
Shigeki Ohtsu shigeki Tokyo, Japan

shigeki/node-class-diagram 64

Class Diagram of Node.js

shigeki/code_and_learn_nodefest_tokyo_2016 15

Code and Learn in Node Festival Tokyo 2016

shigeki/ask_nishida_about_quic_jp 10

QUICトランスポート機能に関して tcpm/mptcp wg chair の西田先生にいろいろ聞いてみる会

shigeki/node-v0.x-archive 8

evented I/O for v8 javascript

shigeki/interop-iij-http2 6

Information for HTTP/20 interop testing for iij-http2

shigeki/libquic 3

QUIC, a multiplexed stream transport over UDP

shigeki/seccamp2015 3

Security Camp 2015

shigeki/challenge_CVE-2020-13777 2

Challange CVE-2020-13777

shigeki/seccamp2015-buffer-workshopper 2

seccamp2015-buffer-workshopper

issue commentWICG/trust-token-api

Feedback of Trust Token V1 from preliminary test in origin trial

we don't want Trust Token API to prescribe any particular format for that. I understood. I did not know it is out of API spec. Thanks.

I also would like to have a non-normative section for that in the spec.

shigeki

comment created time in 4 days

issue commentWICG/trust-token-api

Feedback of Trust Token V1 from preliminary test in origin trial

Thanks for prompt reply.

we don't want Trust Token API to prescribe any particular format for that.

I understood. I did not know it not out of API spec. Thanks.

What error are you having with cross origin redemption?

The error shows that

DOMException: Precondition failed during Trust Tokens operation

I cannot resolve this until I read the step of redemption in design doc. It was helpful for me to describe refreshPolicy: none is only permitted at the same origin in the spec.

I believe this is the normal fetch behavior for a cross-origin request and not related to Trust Token directly

That's right. There is no mismatch. But I was surprised at preflight of options of signed-header which would not required in the case of signRequestData: omit.

I also wonder whether it need mode: cors option is not required or not. The current trust token fetch does not need the option. Right?

Are there cases where doing a catch on the fetch error condition don't work?

It was not confident for me if NoModificationAllowedError is the right error type to know it. I prefer to have an API such as document.hasTrustToken.

We're hoping to eventually have devtools integration to allow you to see some of the Trust Token state and clear it in the Dev Tools pane.

That's great. I made the page of refreshPolicy:none in the same origin to consume tokens instead of clearing them.

shigeki

comment created time in 4 days

issue openedWICG/trust-token-api

Feedback of Trust Token V1 from preliminary test in origin trial

I have made tests against the current Trust Token V1 API to issue, redeem and send-srr in cross origin against my issuer server. Theses are feedbacks from my preliminary tests.

  • Clarify and Describe the verification step when receiving send-ssr I made the following verifications and would like to know if they are correct.
  1. verify the signature of SRR with srrkey
  2. if sec-signature exists 2.1. verify if keyhash in SSR is equal hash of client public key. 2.2 check signed-header list 2.3 compose canonical request data 2.4 verify the signature of canonical request data with client public key 2.5 decode private metadata with XOR of hash of keyhash and metadata key
  • Describe the condition of cross origin redemption more clearly Describe clearly only refreshPolicy: refresh is permitted. Precondition error is hard for me to find the reason of the issue. I also want to know why refreshPolicy: none is allowed only in same origin.

  • Describe the condition of cross origin send srr more clearly It is needed to accept preflight OPTIONS to allow signed-headers for cross origin request.

  • How to know if a redeemed token is cached and when it will expire A cached redeemed token leads an exception of NoModificationAllowedError when redemption request is made. It can happen if we reload the page of redemption before expire. We do not have an API to know if we can know the current token is under cache and when it will be expired.

  • Internal page for development It would be better for me to have an internal page for trust token to show how many token issued per issuer and force to clear the all the issued tokens in Chrome for development.

I hope this would help for the further trials.

created time in 4 days

pull request commentWICG/trust-token-api

fix send-srr example and context string

I joined WICG and the issue of IPR bot was resolved.

shigeki

comment created time in 13 days

pull request commentWICG/trust-token-api

fix send-srr example and context string

Thanks. I send the request and now it is under review.

shigeki

comment created time in 14 days

pull request commentWICG/trust-token-api

fix send-srr example and context string

I've just connected my github account to my w3c.

shigeki

comment created time in 14 days

PR opened WICG/trust-token-api

fix send-srr example and context string

Currently referer is not permitted in the singed header list. sec-time header can be included even when includeTimestampHeader is false, so it can be included in the example.

The current context string is Trust Token v0 not Trust-Token-v1.

+2 -2

0 comment

1 changed file

pr created time in 14 days

create barnchshigeki/trust-token-api

branch : fix_send_srr

created branch time in 14 days

issue openedapache/trafficserver

HTTP/2 GREASE intolerance in 7.1.x

We had an issue with Chrome Dev/Canary that ATS-7.1.x is intolerant to HTTP/2 greasing as https://bugs.chromium.org/p/chromium/issues/detail?id=1100194.

It would be glad for us if https://github.com/apache/trafficserver/pull/5636 is backported to 7.1.x since we've confirmed that it resolves the issue.

created time in 3 months

more