http://microformats.org/wiki/existing-rel-values is the right place to start.

Add it to http://microformats.org/wiki/existing-rel-values#brainstorming

then I'd suggest creating a page on the microformats wiki following the http://microformats.org/wiki/process to discuss it, pointing to existing examples etc.

http://microformats.org/wiki/xfn-brainstorming is a more XFN-focused discussion.

Paul Lindner note that the rel attribute is not for general "tagging" of a target link, this is a common misconception.

Here's an FAQ about rel: http://microformats.org/wiki/rel-faq#What_does_a_rel_value_really_mean.3F

Kevin Marks is right about brainstorming.

However, start with documenting the use case.

In this case, what's the problem you're trying to solve?

I want a stronger assertion than 'me'. Many sites allow a user to place a link to another page with a rel='me'. However sites that properly control markup should be able to add an annotation that denotes that the linked page is 'verified'.

I would have proposed rel="me" rev="me", but that seemed, well, weird.

I'd appreciate your thoughts before I go too far down this path. Another option was parsing tags more strongly than tags, but again that seems a little too implicit and hacky.

This is tricky, as the bidirectional rel="me" is the real confirmation of assertions; you're still implicitly trusting the one-way assertion of verification here. Also, as used now, "verified" tends to be an assertion made about the current page's connection to a supposedly famous human, not another page (see Twitter, Google+ use of Verified badges). OpenID Connect has a 'vefified' boolean with this semantic too (I'm not necessarily defending this practice, just noting folk terminology here).

Are you coming to IIW this week? chaining of Authentication in this way seems like an important topic to talk about there.

Paul Lindner Thanks for the clarification of the use-case.

Your instincts/intuition are fairly accurate here.

rel="me" rev="me" would be precisely semantically correct for a verified "me" relation link. However, HTML5 eliminated the author-problematic 'rev' attribute and thus this approach won't work.

Additionally, yes, making tags mean something thatn tags is too subtle and hacky.

Another way of thinking about this new form of 'me' relation is that a service could publish it to assert that the service itself has crawled the destination of the link and verified that there is a valid rel=me link back to the profile on the service, thus eliminating the need for clients of the service to do the crawling themselves. For that, something like:

<a href="http://inuus.com" rel="me me-verified">Paul

Could work, where we define the relation "me-verified" as meaning, this link over there is another URL for "me" and the current document/site/domain/service has verified that the destination site links back as well.

Of course anyone could make 'me-verified' claims, but this would work well for the 2nd party case, e.g.

1. on Twitter (the 1st party) a user (2nd party) configures their profile to link to their personal site/URL. Twitter automatically adds rel="me" to the link (this works on numerous, dozens, likely hundreds of such services today[1]).

2. The user (1st party) then changes their personal site/URL to have a rel-me link to their Twitter profile URL (users with their own domains typically already have a link to their Twitter profile so all they do as is add rel="me" to that hyperlink, or configure it in their CMS e.g. WordPress to do so).

3. Twitter at some point either passively crawls the user's personal site/URL, or does so triggered by the user clicking a "Verify me" button on their profile (insert your favorite UX here).

4. Then assuming Twitter finds the proper rel-me link at the user's personal site/URL, Twitter updates the link from the user's Twitter profile to have a rel="me me-verified".

Is that a reasonable re-expression of the use-case you're looking for Paul?

as twitter also adds a "nofollow" to their rel="me", maybe verifying the me linkback they could remove that.