Chairs: Darrel, Richard
Secretary: Mark
Minutes: Rich, Erik Kinnear, Momoka
#https://datatracker.ietf.org/doc/draft-schwartz-httpapi-popup-authentication/
slides
(Also presented at OAuth)
"Popup authentication"
see slide.
Martin Thomson: lots of popups are problematic. Does application have to
control the browser, pull out cookies, etc? Right now it's cut/paste
screen display with "the token". That's an important use-case but maybe
not the only thing we need to discuss.
Mike Bishop: Sympathetic to abuse, but it's just a different popup not a
new one. WWhat does this address that "redirect to local server"
doesn't? (missed answer, sorry)
Aaron Parecki: 1st slide is all we need. A lot of things is done in
OAuth. Do need to address new clients not known to oauth server which
isn't within oauth use cases. oauth wg is looking at that.
Pieter Kasselman: be careful around security side; this seems to allow
new lateral or other attacks. Try to avoid having the end-user having to
make a decision, at least give them information to help them avoid
making a bad/insecure decision. Attackers are focusing on the end-user
not the protocol now and getting sophisticated.
Eric Kinnear: We use a custom URI scheme to have auth content come back
to the application.
Ben Schwartz: The difference is that we shouldn't need to hardcode this
for any list of services
Eric Kinnear: Lets reduce the bouncing around. Less user confusion.
Martin Thomson: What does the website know about the client? I'm
thinking of "crates.io" knows me, does the auth, passes that back to the
client. Ben: yes.
Ben Schwartz: the authentication will be from the same origin.
Martin Thomson:
chair: this is useful to HTTPapi world but it's work for OAuth for this
to work.
Ben Schwartz: We will make a more OAuth version of this protocol.
Aaron: I agree to the concerns of unknown clients talking to unknown
servers. Will write what is a assumption and how to deploy it.
OAUTH folks agree to work on this in OAuth.
Roberto: in WGLC, media type people gave positive feedback and
suggestions (e.g., change the extension from yml to .yaml) Main open
issue is clipboard identifiers.
Alexey Melnikov: registration seems fine, MSFT is first-come first-serve
so expect nothing to do; Alexey ee approve it.
Deprecation Header: format of Date header, maintain compatibility
with Sunset header, should we merge? Let's decide now to avoid
revisiting it in IETF 116. Mnot only commenter. HTTP will be using
@integer-since-1970-epoch for dates. They are okay with Deprecation
header. Roberto: prefers human-readable not an integer. Mark: we
will need to reply to IESG if we don't use an existing IETF
practice. Darrel: world is moving to a display aide for headers
Idempotency Key. Last issue to be closed now. Any comments from the
room? Any interest in using it? A couple of non-committal yes's.
Marius: resumable uploads in HTTP WG is thinking of using it.
Link Template. Now uses structured fields. Will handle issue about
"anchor" header using templates. Then ready for WGLC.
schema+yaml: waiting for schema folks to address fragments.
Problem Details for HTTP APIs
Rate Limit Headers. Discussion about one header field with
structured values, versus three "simple" headers. Roberto: believe
industry uses/wants three fields, merging will diverge from industry
practice. Chris: I am sympathetic that intermediaries don't
currently have all the parser, but Im skeptical they won't. Mark:
should not focus primarily on current syntax; RFCs are long-term,
should think of future. If we did this for Cache-control and split
into separate fields it would be bad. Sbhould split headers by
semantics, not just into separate header fields. Roberto: I am
concerned about diverging from practice. Rich: x-ratelimit might be
current practice, things are changing. Chris: are we documenting
existing practice or defining a new standard?
ACTION: Strong consensus for structured fields. Will confirm on the
list, and ask the authors to do a PR that uses structured fields.
https://ietf-wg-httpapi.github.io/
popup-authentication (see above)?