• Revised I-D Needed - Issue raised by WG
  • Awaiting Expert Review/Resolution of Issues Raised
  • Awaiting External Review/Resolution of Issues Raised
  • Awaiting Merge with Other Document
  • Author or Editor Needed
  • Waiting for Referenced Document
  • Waiting for Referencing Document
  • Revised I-D Needed - Issue raised by WGLC
  • Revised I-D Needed - Issue raised by AD
  • Revised I-D Needed - Issue raised by IESG
  • Doc Shepherd Follow-up Underway
  • Other - see Comment Log

IETF :: appsawg

Current state: Submitted to IESG for Publication

Viewing the last 20 entries. Show full log.

2013-04-18 12:29 Joel Jaeggli

[Ballot comment]
converting to no objection, awaiting the resolution of stephen's discuss which will in all likelihood satisfy me.

2013-04-18 12:29 Joel Jaeggli

[Ballot Position Update] Position for Joel Jaeggli has been changed to No Objection from Discuss

2013-04-17 12:34 Ted Lemon

[Ballot comment]
Pete has rightly pointed out that my comments below are more consistent with "Abstain" than "No Objection." In addition to the concern I've expressed below, I also agree with Pete's concern that the specification as to how to issue a query is too vague to promote interoperability.

The more I try to come up with a helpful suggestion for how to make this document do what I think it should with respect to authentication and authorization, the more I feel like I've waded into quicksand. I think that what I originally asked in my DISCUSS is actually impossible, so I've cleared the DISCUSS, not because I feel it's been addressed, but because it's probably unreasonable to ask the authors to address it.

For what it's worth, here's the most recent reply I crafted to Paul Jones on the topic. I don't think what I said in here is exactly right, so I don't propose that the authors do what I ask below, but I also don't think it's completely unreasonable:

On Apr 11, 2013, at 9:46 PM, Paul E. Jones wrote:
> For WebFinger, though, the access control mechanism is HTTP-based
> authentication. It will either be:
> - No authorization required (likely the norm for most queries to
> /.well-known/webfinger)
> - Basic authentication (OK since all requests are over HTTPS)
> - OAuth tokens or similar (not fully explored, but potentially useful
> for allowing trusted third parties to access one of your WF-
> referenced resources)

What I would like to see somewhere in this is first of all that the document explicitly says something like what you just said above—I don't think it does at the moment. Secondly, that it goes into a little more detail about this. I'm thinking about no more than an additional page of text, and preferably less, not a dozen pages.

The detail would include implications of "no authorization." It would talk very generally about per-URI access control on the basis of authentication tokens appearing on access control lists. It would talk very generally about mapping provided authentication information, whether it's none, basic, or OAuth, to roles that appear on access control lists. And it would talk, again very generally, about how to return more or less complete results on the basis of those roles.

You already have text in the document that alludes to this. I'm not asking for something that's hugely more detailed than what's in the document now; it's just that what's in the document now only implies any of this to someone who has already drunk the authentication/authorization kool-aid.

As for why I think you ought to do this when http doesn't do it, it's because this is very clearly a protocol about sharing user-specific information, and the information you're talking about very clearly includes information the privacy of which many users would want to control to varying degrees. A simple binary private/authenticated flag is too coarse, and will lead to people being forced to make unsafe privacy choices.

I don't think you have to define a new authentication protocol, or that you should flesh out a complete authorization and access control system. But I am deeply uncomfortable with the idea of saying nothing about this issue here.

2013-04-17 12:34 Ted Lemon

Ballot comment text updated for Ted Lemon

2013-04-17 12:34 Ted Lemon

[Ballot comment]
Pete has rightly pointed out that my comments below are more consistent with "Abstain" than "No Objection." In addition to the concern I've expressed below, I also agree with Pete's concern that the specification as to how to issue a query is to vague to promote interoperability.

The more I try to come up with a helpful suggestion for how to make this document do what I think it should with respect to authentication and authorization, the more I feel like I've waded into quicksand. I think that what I originally asked in my DISCUSS is actually impossible, so I've cleared the DISCUSS, not because I feel it's been addressed, but because it's probably unreasonable to ask the authors to address it.

For what it's worth, here's the most recent reply I crafted to Paul Jones on the topic. I don't think what I said in here is exactly right, so I don't propose that the authors do what I ask below, but I also don't think it's completely unreasonable:

On Apr 11, 2013, at 9:46 PM, Paul E. Jones wrote:
> For WebFinger, though, the access control mechanism is HTTP-based
> authentication. It will either be:
> - No authorization required (likely the norm for most queries to
> /.well-known/webfinger)
> - Basic authentication (OK since all requests are over HTTPS)
> - OAuth tokens or similar (not fully explored, but potentially useful
> for allowing trusted third parties to access one of your WF-
> referenced resources)

What I would like to see somewhere in this is first of all that the document explicitly says something like what you just said above—I don't think it does at the moment. Secondly, that it goes into a little more detail about this. I'm thinking about no more than an additional page of text, and preferably less, not a dozen pages.

The detail would include implications of "no authorization." It would talk very generally about per-URI access control on the basis of authentication tokens appearing on access control lists. It would talk very generally about mapping provided authentication information, whether it's none, basic, or OAuth, to roles that appear on access control lists. And it would talk, again very generally, about how to return more or less complete results on the basis of those roles.

You already have text in the document that alludes to this. I'm not asking for something that's hugely more detailed than what's in the document now; it's just that what's in the document now only implies any of this to someone who has already drunk the authentication/authorization kool-aid.

As for why I think you ought to do this when http doesn't do it, it's because this is very clearly a protocol about sharing user-specific information, and the information you're talking about very clearly includes information the privacy of which many users would want to control to varying degrees. A simple binary private/authenticated flag is too coarse, and will lead to people being forced to make unsafe privacy choices.

I don't think you have to define a new authentication protocol, or that you should flesh out a complete authorization and access control system. But I am deeply uncomfortable with the idea of saying nothing about this issue here.

2013-04-17 12:34 Ted Lemon

[Ballot Position Update] Position for Ted Lemon has been changed to Abstain from No Objection

2013-04-17 12:19 Pete Resnick

[Ballot discuss]
There appears to be a big giant semantic gap for the client side of this protocol. I can find nothing in the document that indicates to the client how it shall determine what sort of URI to use is the resource part of the query or what the semantics of any given URI are supposed to be. Indeed, the -13 version of the document adds a paragraph more or less saying that this is intentional:

The WebFinger protocol is designed to be used across many
applications. Applications that wish to utilize WebFinger will need
to specify properties, titles, and link relation types that are
appropriate for the application. Further, applications will need to
define the appropriate URI scheme to utilize for the query target.

I suspect that the semantics are so underspecified that there could not possibly be interoperable implementations without lots of out-of-band information.

1. The first example provides a mapping from an email address (or perhaps a mailto URI; that's not clear) to an acct URI, but neither the example nor anything in the rest of the document gives any clue why you would choose to query an "acct" URI based on the contents of an email message. I think the assumption is that if there is an email address, there must be some sort of "account" associated with it, and therefore querying the host on the RHS of the "@" for that account will get some interesting information. But I don't see any reason to choose an "acct" scheme over "mailto" or "smtp" or "email" or "foobar"; as far as I can tell, the choice is semantics-free.

Reading the above alongside 3.3 makes me all the more suspicious: In 3.3 (also mentioned in 4.5), a "mailto" URI gets you configuration information for all email configuration parameters. Does an "acct" URI get you configuration information for email *and* xmpp *and* sip *and* calendaring *and* all other configuration information (since you are no longer asking for a particular protocol, but rather the general account information), or do you only get "information" about the person and not their account? How can the client know what sort of information it can ask for and how to get it? And for that matter, how does the server tell what information to pass back? You'd think there would be a hint about this in 4.3, but "rel" only seems to provide for the client to request those things that the client already knows about it. In particular, there appears to be no way to say, "Give me user provided information, but not config information" or "Give me config information, but not blog entries". If the intention of the document is to ignore this issue and leave it to other documents or just the implementation to define (as implied by the new paragraph in the intro), I'd say that this protocol is not complete and therefore not interoperable.

2. I disagree with Benoit about the need for Webfinger to return only static info and therefore object to the addition of the text to the intro regarding static vs. dynamic:

The information is intended to be static in nature and, as such,
WebFinger is not intended to be used to return dynamic information
like the temperature of a CPU or the current toner level in a laser
printer.

Benoit's objection is certainly a design preference, but is not appropriate as a DISCUSS and certainly is not an appropriate change to make without WG consensus, which was not obtained. I think it is perfectly reasonable for Webfinger to return dynamic information (indeed, it certainly will in the case of human account information), and this restriction is inappropriate just to satisfy a particular AD's preferences.

2013-04-17 12:19 Pete Resnick

[Ballot comment]
1. After discussions, I now understand why a URI might be useful as the resource target of a query. (E.g., I might want to see if there is information about a particular web page that will lead me to its author, etc.) However, I am still a bit confused about why a URI is the *only* thing I can query. The new text on the importance of the host info increases this confusion:

The host to which a WebFinger query is issued is significant. If the
query target contains a "host" portion (Section 3.2.2 of RFC 3986),
then the host to which the WebFinger query is issued MUST be the same
as the "host" portion of the query target. If the query target does
not contain a "host" portion, then the client MAY choose a host to
which it directs the query based on local policy.

If the URI need not have a host portion and you can therefore target any host, I don't see why the resource portion of the query needs to be a URI. As I said earlier, it seems reasonable to pass any sort of identifier. (See http://datatracker.ietf.org/doc/draft-ietf-radext-nai/ for example.) If more semantics (beyond rel) are needed, another parameter indicating the type of identifier being used seems much more appropriate than using a URI scheme.

2. I see no justification for the restriction in the above for querying only the host that is in the host portion of a URI. Please explain.

3. I agree with Stephen's concerns re: privacy.

2013-04-17 12:19 Pete Resnick

Ballot comment and discuss text updated for Pete Resnick

2013-04-17 09:11 Richard Barnes

[Ballot Position Update] Position for Richard Barnes has been changed to No Objection from Discuss

2013-04-17 05:49 Stephen Farrell

[Ballot discuss]

This is just a quick update to clear the discuss points
that are obviously already handled in -13. Some
points are not yet ready to clear, but I need to update
the discuss text as -13 does partially address point
(1) in particular.

I'll get that done later, hopefully today/tomorrow.

I've not touched the comments below so far except
to make what was discuss point (5) a comment.

----

As will be seen, I (still) have issues with the privacy
aspects of this specification. Some of those are most
apparent through the use-cases/examples so I've taken the
unusal step of DISCUSSing those since they really seem to
convey the real intent of this protocol. To an extent, some
of the suggested changes there do represent personal
preferences of mine but I believe that the DISCUSSion is
still worth having between the authors and IESG and perhaps
the WG.

(1) 3.1, having the MUA automatically do the webfinger thing
is a privacy disaster and would cause MUAs to visit sources
of spam continually and to expose the email addresses of
their correspondents. Other references to having a UA
automatically do webfinger also need to be deleted kind of
behaviour needs to be the subject of a "MUST NOT" statement
IMO. In fact, it already is, since 8.2 says: "WebFinger MUST
NOT be used to provide any personal data to any party unless
explicitly authorized by the person whose information is
being shared." Having a MUA automatically send out a WF
request where the query target is the mail sender/from
contradicts this requirement. The 3.1 example also fits the
anti-pattern given in 8.3. Suggested fix, easy: say that a
MUA MUST NOT do the automatic thing, as per 8.2, which would
be a fine forward reference.

(2) 3.3, this example is odd - why should Sue expose her
username in this interaction - there's no occurrence of
anything clearly user-dependent in the response except what
was given in the request. Why should we expose user
information unnecessarily in this manner? I think the fix
here is for user Sue to send a request for "anon@example.com"
and for the text to specifically say that making use of the
real username isn't a good plan and making use of an invented
non-existent string for username in this case is a fine plan
and perhaps even specifying such a "nonexistent" username
value that can be supported by and understood by all clients
and servers and saying when it'd be sensible to use that.

(3) 3.4, making devices discoverable like this, esp if device
type and firmware revisions were to be exposed represents a
significant increase in an existing risk. (We had a recent
discussion related to vCard for a similar use case.) This
section seems to be too speculative to be honest, so I'd
suggest just deleting it. If not, maybe add text like that
added in the vCard case.

(4) cleared

(5) made this a comment

(6) cleared

2013-04-17 05:49 Stephen Farrell

[Ballot comment]

Was discuss point (5). Since nobody else is arguing for
this I've made it a comment.

- 8.2 and 8.3, given the privacy and abuse considerations
here why is there no definition for the DELETE method in
order to provide a way for users to be able to at least ask
that their information no longer be available? Or another
.well-known URI could be used. Was that discussed?

---

- Thank you for requiring TLS! That's a good precedent.

- intro: "facilitate logging into a web site" hmm, lots of
security alarm-bells ring there, maybe better to say
"facilitate, with additional security mechanisms, logging
into a web site" or choose a non-security example?

- 3.2, I'd much prefer that the security of this kind of
interaction be explained, if only by reference, e.g. add
something like "the security aspects of this kind of
interaction are discussed in [ref]." If such a [ref] exists
then that ought be easy and useful. If no such [ref] exists
that would be interesting.

- 4.1, I'm a bit confused here. Can I use WF to ask about
"http://tcd.ie/thing?foo=bar&baz=bat" as the query target? I
think this section says that's ok but I'm not sure so maybe
I'm confused. Maybe making that explicit would be good. I'm
also not sure that its ok to not percent-encode the "?" in
that query target but I guess it must be ok if you've said
nothing about it.

- 4.3, the example "rel"s are http URLs and not https. Are
these intended never to be de-referenced? If so, maybe say
so and that its therefore ok to not insist on https? If not,
then I think you do need to say that de-referencing those
URLs can invalidate some of the confidentiality guarantees
provided by requiring TLS for WF.

- 4.4.3, same comment as for 4.3; maybe for 4.4.4.x too

- section 7 uses the term "service URI" - I think that and
"query target" and "subject URI" would be better defined up
front

- 8.1, you don't say if you require certificate status
checking. It'd be better to say.

- 8.2, this is outstandingly glib: "If one does not wish to
share certain information with the world, do not allow that
information to be freely accessible on the Internet or
discoverable via WebFinger" - most users are never given a
choice as to whether or not much of their information is
freely accessible or not. I think the best that can be done
with that is to delete it.

2013-04-17 05:49 Stephen Farrell

Ballot comment and discuss text updated for Stephen Farrell

2013-04-16 23:31 Benoit Claise

[Ballot Position Update] Position for Benoit Claise has been changed to No Objection from Discuss

2013-04-16 19:54 (System)

Sub state has been changed to AD Followup from Revised ID Needed

2013-04-16 19:54 Paul Jones

New revision available

2013-04-11 19:56 Ted Lemon

[Ballot comment]
The more I try to come up with a helpful suggestion for how to make this document do what I think it should with respect to authentication and authorization, the more I feel like I've waded into quicksand. I think that what I originally asked in my DISCUSS is actually impossible, so I've cleared the DISCUSS, not because I feel it's been addressed, but because it's probably unreasonable to ask the authors to address it.

For what it's worth, here's the most recent reply I crafted to Paul Jones on the topic. I don't think what I said in here is exactly right, so I don't propose that the authors do what I ask below, but I also don't think it's completely unreasonable:

On Apr 11, 2013, at 9:46 PM, Paul E. Jones wrote:
> For WebFinger, though, the access control mechanism is HTTP-based
> authentication. It will either be:
> - No authorization required (likely the norm for most queries to
> /.well-known/webfinger)
> - Basic authentication (OK since all requests are over HTTPS)
> - OAuth tokens or similar (not fully explored, but potentially useful
> for allowing trusted third parties to access one of your WF-
> referenced resources)

What I would like to see somewhere in this is first of all that the document explicitly says something like what you just said above—I don't think it does at the moment. Secondly, that it goes into a little more detail about this. I'm thinking about no more than an additional page of text, and preferably less, not a dozen pages.

The detail would include implications of "no authorization." It would talk very generally about per-URI access control on the basis of authentication tokens appearing on access control lists. It would talk very generally about mapping provided authentication information, whether it's none, basic, or OAuth, to roles that appear on access control lists. And it would talk, again very generally, about how to return more or less complete results on the basis of those roles.

You already have text in the document that alludes to this. I'm not asking for something that's hugely more detailed than what's in the document now; it's just that what's in the document now only implies any of this to someone who has already drunk the authentication/authorization kool-aid.

As for why I think you ought to do this when http doesn't do it, it's because this is very clearly a protocol about sharing user-specific information, and the information you're talking about very clearly includes information the privacy of which many users would want to control to varying degrees. A simple binary private/authenticated flag is too coarse, and will lead to people being forced to make unsafe privacy choices.

I don't think you have to define a new authentication protocol, or that you should flesh out a complete authorization and access control system. But I am deeply uncomfortable with the idea of saying nothing about this issue here.

2013-04-11 19:56 Ted Lemon

Ballot comment text updated for Ted Lemon

2013-04-11 19:55 Ted Lemon

[Ballot comment]
The more I try to come up with a helpful suggestion for how to make this document do what I think it should with respect to authentication and authorization, the more I feel like I've waded into quicksand. I think that what I originally asked in my DISCUSS is actually impossible, so I've cleared the DISCUSS, not because I feel it's been addressed, but because it's probably unreasonable to ask the authors to address it.

For what it's worth, here's the most recent reply I crafted to Paul Jones on the topic. I don't think what I said in here is exactly right, so I don't propose that the authors do what I ask below, but I also don't think it's completely unreasonable:

On Apr 11, 2013, at 9:46 PM, Paul E. Jones wrote:
> For WebFinger, though, the access control mechanism is HTTP-based
> authentication. It will either be:
> - No authorization required (likely the norm for most queries to
> /.well-known/webfinger)
> - Basic authentication (OK since all requests are over HTTPS)
> - OAuth tokens or similar (not fully explored, but potentially useful
> for allowing trusted third parties to access one of your WF-
> referenced resources)

What I would like to see somewhere in this is first of all that the document explicitly says something like what you just said above—I don't think it does at the moment. Secondly, that it goes into a little more detail about this. I'm thinking about no more than an additional page of text, and preferably less, not a dozen pages.

The detail would include implications of "no authorization." It would talk very generally about per-URI access control on the basis of authentication tokens appearing on access control lists. It would talk very generally about mapping provided authentication information, whether it's none, basic, or OAuth, to roles that appear on access control lists. And it would talk, again very generally, about how to return more or less complete results on the basis of those roles.

You already have text in the document that alludes to this. I'm not asking for something that's hugely more detailed than what's in the document now; it's just that what's in the document now only implies any of this to someone who has already drunk the authentication/authorization kool-aid.

As for why I think you ought to do this when http doesn't do it, it's because this is very clearly a protocol about sharing user-specific information, and the information you're talking about very clearly includes information the privacy of which many users would want to control to varying degrees. A simple binary private/authenticated flag is too coarse, and will lead to people being forced to make unsafe privacy choices.

I don't think you have to define a new authentication protocol, or that you should flesh out a complete authorization and access control system. But I am deeply uncomfortable with the idea of saying nothing about this issue here.

2013-04-11 19:55 Ted Lemon

Ballot comment text updated for Ted Lemon

Viewing the last 20 entries. Show full log.