Query about atom:id and author:uri for Activities w/Salmon
John Panzer
Martin Atkins
Reading between the lines, it looks like the requirement is that there
must be some URL available that:
* is resolvable.
* supports whatever discovery protocol Salmon has defined for
retrieving a signing key.
The atom:id does not satisfy either of these constraints, because it's
explicitly defined in the spec that you must not rely on it being
resolvable and since it can be of any arbitrary URL scheme there is no
guarantee that you can do discovery of any kind on it.
The atom:uri *does* satisfy the first of these, but Atom says nothing
about the second because this is something Salmon has invented.
Therefore you can't just assume that any URL in this field will support
discovery.
With that in mind, it feels to me like what you actually need is a new
field whose value is defined to be a URL conforming to your unique
constraints, rather than trying to impose additional constraints on an
existing field.
Martin Atkins
>
>
> The atom:uri *does* satisfy the first of these, but Atom says nothing
> about the second because this is something Salmon has invented.
> Therefore you can't just assume that any URL in this field will support
> discovery.
>
In fact, I'm mistaken in this assertion. RFC4287 says nothing about the
value of atom:uri except that it MUST be an IRI. This makes it no more
useful for your discovery use-case than the atom:id field, unless I'm
missing something.
John Panzer
Reading between the lines, it looks like the requirement is that there must be some URL available that:
* is resolvable.
* supports whatever discovery protocol Salmon has defined for retrieving a signing key.
The atom:id does not satisfy either of these constraints, because it's explicitly defined in the spec that you must not rely on it being resolvable and since it can be of any arbitrary URL scheme there is no guarantee that you can do discovery of any kind on it.
The atom:uri *does* satisfy the first of these, but Atom says nothing about the second because this is something Salmon has invented. Therefore you can't just assume that any URL in this field will support discovery.
With that in mind, it feels to me like what you actually need is a new field whose value is defined to be a URL conforming to your unique constraints, rather than trying to impose additional constraints on an existing field.
On 04/06/2010 03:59 PM, John Panzer wrote:
Salmon has an issue with Activity Entries. Thoughts? (Note that this
is introduced by Activity Streams as AS adds atom:id underneath author;
there's no issue for generic Atom entries.)
http://code.google.com/p/salmon-protocol/issues/detail?id=14#makechanges
In discussion w/Will Norris, we came up with an issue. If an entry is an
Activity and the author(actor) has both a URI and a globally unique
atom:id, there's an issue with which identifier to rely on. The URI is
discoverable and can be linked directly to the public signing key. The
atom:id, if present, is not necessarily discoverable (it is often a tag:
URI) and is a permanent, persistent identifier that would be a good
candidate for a primary foreign key for that person. However, verifying
the Magic Signature just verifies that the author/atom:uri claims that
author/atom:id, not that they actually own it. Thus I could sign a Salmon
which has author/atom:id belonging to Will.
So 3 possible resolutions here: (1) When using signed entries, the atom:id
of the author(actor), if present, MUST be ignored; (2) When using signed
entries, the atom:id of the author(actor), if present, MUST be a
discoverable URI (http(s): or acct:, not tag:); or (3) something else.
--
You received this message because you are subscribed to the Google Groups "Activity Streams" group.
To post to this group, send email to activity...@googlegroups.com.
To unsubscribe from this group, send email to activity-strea...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/activity-streams?hl=en.
John Panzer
Martin Atkins
>
> The problem is that we need to bind the public key to the user's
> identity, and Salmon does not want to invent a new system for identity.
> It's inventing enough already :). An existing URI, which can be
> easily annotated via Webfinger-style discovery, is highly attractive for
> this reason.
>
Whether you call it atom:uri, atom:id or salmon:uri it's still a new
thing that hasn't existed in either Atom or Activity Streams until now.
I certainly don't disagree that it's attractive to use a discoverable
URI as the identity, but I do disagree that stuffing it into either
atom:id or atom:uri, which already have established meanings which don't
suit your requirements, is a good design.
Of course, if this additional restriction on Atom only applies within
Salmon protocol payloads then it doesn't matter so much what you do.
Interoperability with existing feed content is not important in that
case, so it doesn't really matter what you do as long as all Salmon
implementations agree on it.
John Panzer
On 04/06/2010 04:28 PM, John Panzer wrote:Whether you call it atom:uri, atom:id or salmon:uri it's still a new thing that hasn't existed in either Atom or Activity Streams until now.
The problem is that we need to bind the public key to the user's
identity, and Salmon does not want to invent a new system for identity.
It's inventing enough already :). An existing URI, which can be
easily annotated via Webfinger-style discovery, is highly attractive for
this reason.
I certainly don't disagree that it's attractive to use a discoverable URI as the identity, but I do disagree that stuffing it into either atom:id or atom:uri, which already have established meanings which don't suit your requirements, is a good design.
Of course, if this additional restriction on Atom only applies within Salmon protocol payloads then it doesn't matter so much what you do. Interoperability with existing feed content is not important in that case, so it doesn't really matter what you do as long as all Salmon implementations agree on it.
Chris Messina
--
You received this message because you are subscribed to the Google Groups "Activity Streams" group.
To post to this group, send email to activity...@googlegroups.com.
To unsubscribe from this group, send email to activity-strea...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/activity-streams?hl=en.
--
Chris Messina
Open Web Advocate, Google
Personal: http://factoryjoe.com
Follow me on Buzz: http://buzz.google.com/chrismessina
...or Twitter: http://twitter.com/chrismessina
This email is: [ ] shareable [X] ask first [ ] private
Bill de hOra
> discoverable and can be linked directly to the public signing key. .
> atom:id, if present, is not necessarily discoverable
I don't understand how the discoverable distinction is being made. The
difference between atom:id and atom:uri is that atom:uri can be an IRI
reference (ie can have a fragid and be relative) whereas an atom:id is
an IRI. How is atom:id not discoverable?
If we're talking denotation or referents then a literal reading of Atom
suggests that atom:uri does not denote a person (it might denote their
homepage for example). An atom:id as defined by AS does denote a person,
but that's scoped to AS (another spec could in theory come along and
define atom:person/atom:id as denoting something else, albeit that would
be a strange usage).
> there's an issue with which identifier to rely on
It would help if you could say what you're trying to identify. This is
probably more important to get right than discovery.
Bill
> jpa...@google.com <mailto:jpa...@google.com> / abstractioneer.org
> <http://www.abstractioneer.org/> / @jpanzer
Danny Ayers
On 7 April 2010 00:59, John Panzer <jpa...@google.com> wrote:
> Salmon has an issue with Activity Entries. Thoughts? (Note that this is
> introduced by Activity Streams as AS adds atom:id underneath author; there's
> no issue for generic Atom entries.)
> http://code.google.com/p/salmon-protocol/issues/detail?id=14#makechanges
>
> In discussion w/Will Norris, we came up with an issue. If an entry is an
> Activity and the author(actor) has both a URI and a globally unique
> atom:id, there's an issue with which identifier to rely on. The URI is
> discoverable and can be linked directly to the public signing key. The
> atom:id, if present, is not necessarily discoverable (it is often a tag:
> URI) and is a permanent, persistent identifier that would be a good
> candidate for a primary foreign key for that person. However, verifying
> the Magic Signature just verifies that the author/atom:uri claims that
> author/atom:id, not that they actually own it. Thus I could sign a Salmon
> which has author/atom:id belonging to Will.
Woo-woo
about 50%
> So 3 possible resolutions here: (1) When using signed entries, the atom:id
> of the author(actor), if present, MUST be ignored; (2) When using signed
> entries, the atom:id of the author(actor), if present, MUST be a
> discoverable URI (http(s): or acct:, not tag:); or (3) something else.
>
> Thoughts?
>
> --
> John Panzer / Google
> jpa...@google.com / abstractioneer.org / @jpanzer
>
> --
> You received this message because you are subscribed to the Google Groups
> "Activity Streams" group.
> To post to this group, send email to activity...@googlegroups.com.
> To unsubscribe from this group, send email to
> activity-strea...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/activity-streams?hl=en.
I believe you have to slow down a little, and positiion those things properly.
Danny Ayers
John Panzer
--