FindMeOn® Specification Document 0.010 2018/10/10 (c) copyright 2006-2019 FindMeOn, Inc / Jonathan Vanasco (jvanasco@FindMeOn.com) FindMeOn® is a registered trademark of FindMeOn inc. -------- Intro findmeon® is an open specification for asserting and verifying ownership of online elements in a decentralized manner FindMeOn.com is a commercial venture that simplifies adopting the standard for end users and sharing information across systems findmeon.org is an open source repository of tools to implement the standard for advanced users Please note the capitalization difference between the two. -------- In Short What? findmeon is a decentralized standard for asserting and verifying ownership of online resource findmeon does this by abstracting your identity into a cryptographic public/private key pairing that signs and verifies bits of information that talk about your relation to an online resource Why? We've found that people tend to have, on average, at least 7 online identities ( email accounts, instant messengers, social network memberships , etc ) -- and they often have more. People are often known by different names on different services People often have trouble linking different services together findmeon was originally the verification and authentication framework for RoadSound.com-- developed to ensure fans that verified information came directly from Bands, Labels, Booking Agents, Venues and Promoters. It was also used to map roadsound user accounts to their personalities on other services. findmeon was split out from RoadSound in April 2006 into its own project, and migrated from a proprietary id system to digital keys shortly thereafter. How does it work? You create a snippet of information that includes the resource, your asserted relation to it, and the current time. You then cryptographically sign that information with your private key. Information on your public key, as well as other online sites are contained in the snippet of information. Your identity across different sites is alleged by a list of other resources (or a centralized repository). Your identity is verified by your digital signature on each site. What do websites need to do to implement it? Nothing. findmeon is user-driven: any user can claim ownership of a resource that they have 'write' or 'send/receive' access to. websites providers do not need to add any additional support Why Not ____? w3.org xml signature - Does not validate within html strict namespace w3.org digital signature -Abandoned, does not validate within html strict namespace OpenID - Decentralized system based on login & authentication. findmeon does not support identity in terms of login, but identity in terms of ownership. OpenID is the opposite. OpenID also requires the site operator to adopt the OpenID system. Passport - Centralized login system. Requires the site to adopt the Passport system. Sxip - Distributed and centralized login system. Requires the site to adopt the sxip system. LID/SAML/etc- See above microid - No verification , easily spoofed. So instead? findmeon is a hodgepodge of the w3.org ideas (along with some other open standards), and using the microformat approach of coercing information into a XHTML1.0 standards compliant format, and a bit of protocol to connect-the-dots. Like OpenID, findmeon is decentralized and open source - anyone can be their own verification authority or key generator with the free OpenSSL package. Since the system is distributed and decentralized, and supports key shielding, a key server is not needed. I thought OpenID did this?! No. OpenID and findmeon address two very different concepts of identity. OpenID is designed for an authentication identity-- verifying identity in a login/challege type of situation. When a person uses OpenID, they're authenticating against a server to say "Hey, can I authenticate here" or "Hey, can you please transfer these profile attributes for me?". findmeon is a protocol to digitally sign a URL / entity. It's like a little flag that sits on a website and says "Hey, ___ owns this website!". Unlike OpenID, it is self verifying and provides for anonymity. FindMeOn is not meant to replace or overlap OpenID in any way shape or form. In a real life scenario you'd use OpenID to register with a forum or post comments to a blog; and findmeon to digitally sign your forum profile and link it to a social networking account. What About FOAF/XFN? FOAF/XFN describes your relationships. FOAF does not validate in XHTML. XFN does. FOAF is not embed-able. XFN is. FOAF/XFN are not verifiable outside of their own context. Using FOAF/XFN as-is, you get a FOAF/XFN document. Using FOAF/XFN+findmeon you get this: a@b.com creates a findmeon for his social networking page a@b.com creates a findmeon for another social networking page a@b.com creates a findmeon for his email address a@b.com creates a findmeon for his foaf/XFN document that is stored online, or signs his foaf/XFN document using the same key used to create findmeon nodes With findmeon each one of these items can be independently verified and networked against each other by anybody who is given the shared public key. AND each one of these items now fits into XHTML Strict and validates nicely for both claiming and verification. What kind of digital signature is this using? The 1.x spec for findmeon is RSA 1024 Keys + SHA1 Digest RSA and SHA1 algorithms are both freely supported through: OpenSSL OpenSSL + Language Bindings Pure (Perl|Python|Ruby|etc) Implementations RSA was chosen over DSA because it places a higher burden of computation on the message signing , than it does on the signature verification. That sounds amazing, could it get any better? Sure! This is just the 1.x target spec The 2.x spec is slated to use web-of-trust keyrings to deliver better cryptographic friendships Origins / Maintenance: The findmeon specification was developed as an immediately implementable solution for content syndication and identity verification by RoadSound.com , a syndicated content management system for the recording industry. The specification was explicitly designed for use in open-source/decentralized environments , so it was split into its own project FindMeOn.com. FindMeOn.com maintains ownership on the specification, but has released it as an open protocol under the Creative Commons Attribution-No Derivative Works 2.5 License. The specification syntax and workings are essentially a subset of XML-DSIG merged with FOAF/XFN vocabulary and ideas. We stripped out a lot of the stuff that makes the specification 'too customizable' ( read confusing / unusable ) , and pushed the syntax to be more in line with the FOAF/XFN projects people already use and like. -------- The Specification The findmeon node structure is released as an open standard that people may freely use and adopt The findmeon node structure is similar to microformats- it is machine readable, with human readable elements, and validates within the xhtml-strict namespace. ( it is not an actual microformat ) The findmeon standard works on this principle: An entity asserts ownership of a resource by making an 'asserted' statement , signing it with a private key , and placing a node structure of information on the resource. The node structure contains a packet of information including: a statement asserting ownership, a digital signature of the statement using the owner's private RSA encryption key [optionally] the owner's public RSA key or information to obtain the public key The public key is an optional element, because: a- The key need only be shared with whomever the individual wants to verify ownership with (which may be a specific individual(s), and not the public at large ) b- If a public key is known, one can use google to find all pages containing that public key which SUGGESTS that either 1) they all share a same author OR 2) individual(s) want to suggest a shared ownership ( putting a piece of text on a page is simple, anyone can 'spoof' a public key ) If the public key is included, one need only validate the contents of the asserted tag using the key A SeeAlso section may be included as well, which allows for the dynamic linking of one or more resources together. This has an implicit benefit of creating a self-contained 'web ring' around the keyholder's identity. FindMeOn.com is a commercial venture that operates: a service that manages key pairs for users and helps them plant them on various resources a service that aggregates and abstracts shared identity information a service that vouches for verification for accounts that are not verifiable en-masse (ie instant messenger accounts or email accounts ) A findmeon node structure looks like this "Long" "Short" "Compressed" findmeon Structure Explained Long v Short v Compressed Long is preferred, but its tough to get the Long format into many online profiles - its too long, and a way to condense stuff to fit needs to be explored. So short was decided. short has all of the long elements, but some multi-node items are condensed into a single node. it results in a savings of 30-60% 'weight', which is needed for many online profiles. Because some forum / sn software aggressively limits tags and attributes, findmeon nodes need to be serializable into another format as well. we came up with Compressed, which is an href to a url that doesn't exist, and where the content of every section is url encoded findmeon is inserted in a standards compliant way ( re: w3c validation and microformat approach ) items are stored in a series of nested tags. span is the default/preferred tag as it does not affect document layout (vs 'div', which does). span is not required to be the tag-- specifically the Spec and SeeAlso elements could be better utilized with tags However, is required to be the outermost tag. findmeon is designed to be invisible by default- there's nothing that needs to be rendered. if you want to display the information, include it in the tag contents. parsers of findmeon tags should look first at the tag - if there is no title, then derive info from the contents. this way a human viewable 'pretty' link does not take precedence over an href. ie: parsers treat the following tags as a representation of " resource='https://findmeon.org/spec/0_09' " https://findmeon.org/spec/0_09 FindMeOn Spec PLEASE NOTE: writing a tag in different manners WILL affect the digital signature. findmeon mostly uses naming conventions derived from the w3c specifications this section explains the class definitions findmeon parent node, located in a href tag. the href is to the published spec version that is used Spec the specification version the node structure adheres to this is important, as the specification states the required digest and encryption methods, as well as node structure The current specification is: https://findmeon.org/spec/0_09 Where 0_09 == 0.09 Concurrent alternate specifications may be introduced at a later date ( ie https://findmeon.org/spec/0_09-DSA ) Hard-coding the structure and encryption into the node structure was a design choice: SignedInfo an asserted statement a list of claims against the resource, including the resource, the resource type and subtype, attributes, and the timestamp at which it was taken ';' , '|' and ',' characters are invalid as they are used as delimiters. since findmeon both addresses and embeds on predominantly http items, the correct escape mechanism is to url-encode / url-escape these characters Signature SignatureValue base64 represented value of RSA::sign(SignedInfo) KeyInfo KeyInfo is optional if supplied, either 1- 'span' tag with public key as the title / content 2- 'a' tag with a href address to a page that contains the public key in another findmeon node, or a url of nothing but the public key SeeAlso an optional list of linked items this is how you 'connect the dots' -- they can be used to create a ring of connected findmeons ;|, characters are invalid as they are used as a delimiter these items should contain findmeon nodes that can be verified by the same public key give an optional title/rel to point to a: 'repository' => repository of multiple findmeon nodes 'foaf' => a foaf document 'xfn' => a page with xfn data 'openid' => a page with openid server info 'me' => the xfn standard for self-referential links please note: the items SeeAlso lists are not verified: they are not within the SignedInfo tag, nor should they be. These items are merely alleged. To verify the items, they must contain a FindMeOn node or another digital signature tied to the same Public/Private key pairing. in long form, this is a series of a tags in short form, this can be a single joined tag SignedInfo components: resource: Resource is the item authority is asserted against Resource is a REQUIRED element resource is mapped as such [ service name ] :// [ address ] This holds true for all IANA assigned ports https://www.iana.org/assignments/port-numbers Examples: https://path/to/url ftp://path/to/url telnet://path/to/url Email addresses are as such: email://user@domain.com Instant messengers are as such: chat://serviceprovider:username Examples: chat://aim:findmeon chat://msn:findmeon for things like skype and aim, stuff gets tricky: they have non IANA assigned urls-- browsers respect aim:NAME skype:NAME callto:NAME -- so any one of those could conceivably work as its own resource Type: Type describes the resource Type is a REQUIRED element 'url' - for IANA registered services 'email' - for email addresses 'chat' - for instant messengers 'account' - for an account type 'real name' - for a name SubType: SubType refines the resource SubType is a REQUIRED element These are the currently accept subtypes, broken down by type url homepage business blog social network profile online account webservice FOAF XFN email personal business instant messenger AIM Yahoo MSN Jabber Google ICQ real name Legal Name Born Name / Maiden Name Nickname Known Name online account Yahoo Google Skype AOL Please note that company names / standards use the capitalization scheme that the owners/maintainers publicly use. Special: Special is an optional element. We won't explain it here. It is usually best to leave out. Attributes: Attributes is a , separated list of additional information about the resource Attributes is an OPTIONAL element primary alternate personal work Timestamp: 'Timestamp' provides a temporal marker for the resource 'Timestamp' is a REQUIRED element 'Timestamp' is a Timestamp value "YYYY-MM-DD HH:MM:SS[GMT difference]" GMT difference is optional. if included it is a whole integer preceded by a + or - character. TimestampExpiration: 'TimestampExpiration' provides a temporal marker for the duration of the resource's validity. "YYYY-MM-DD HH:MM:SS[GMT difference]" GMT difference is optional. if included it is a whole integer preceded by a + or - character. 'TimestampExpiration' is an optional element. If omitted, a default value of 1 YEAR is assumed. 'TimestampExpiration' has a maximum length of 1 year. Any assertion of an expiration date more than 1 year after 'Timestamp' should be ignored, and 1 YEAR used instead. Invalidated: OPTIONAL element. Only include if true. Only valid value is a Timestamp "YYYY-MM-DD HH:MM:SS[GMT difference]" GMT difference is optional. if included it is a whole integer preceded by a + or - character. 'Invalidated' is used to 'unsign' a previously signed resource tied to a private key. 'Invalidated' states that a resource is no longer verifiable by the Private Key holder AFTER the Timestamp listed as the 'Invalidated' value. The Timestamp in 'Invalidated' can , ( and often is ) an earlier date than the 'Timestamp' field. The 'Timestamp' field is a record of the moment-of-signing. The 'Invalidated' date is an assertion as to when a signed resource is not longer valid. 'Invalidated' obviously need not be located on the same 'Resource' as it expires -- but must be signed with the same Private Key. A findmeon signature remains VERIFIED for the period of 1 year, unless a sooner expiration date is provided using the optional 'TimestampExpiration' field. After such time, it should be considered VERIFIED- from that point onwards. This is only to provide for continual timeliness. Please see the section below on STATUS LEVELS for a better explanation. SPECIAL CASES While it is EXTREMELY unlikely that a key pairing is spoofed, it is extremely possible that a key pairing is compromised ( the pairing is known to an individual other than the actual owner ). In this situation , a key can be invalidated following this procedure: Create a node with the resource as key://compromised A timestamp is required , but irrelevant- once a key is stated to be compromised, all items signed with it (past, present, future) should be considered compromised. The timestamp is used solely for locating recently compromised keys. A timely timestamp should lead to quicker invalidation. Optionally include a list of SeeAlsos to invalidate Optionally include the public key or a link to the public key that is now invalid. authors of a key://compromised node should publish the node where search engines can find it and index it along with the timestamp. preferably, list it on the same URL as http addresses once publicly signed for it- that should aid indexers in culling compromised data. Example: Should this node ever be created, all verifications tied to the public key REGARDLESS OF TIMESTAMP should be regarded as potentially compromised. There are two possible scenarios under which this node would be created a- the True Identity owner wants to invalidate any compromised nodes from being created with a compromised key b- the key thief wants the public to invalidate any legitimately signed nodes If the public key is included or provided to any verification system , and that system that can verify the Signature for key://compromised , they should IMMEDIATELY consider anything tied to that public key as invalid and worthless. key://compromised is a method to completely destroy a key and its history. There are several tags for other situations that will come in a future version of the document: A special case is when someone has lost ownership of a resource, and wishes to 'unclaim' an already verified findmeon. For example: In March you have "iLoveTheSpring.randomBlogService.com" In Septemeber you have "iLoveTheFall.randomBlogService.com", and are no longer associated with the fall. The new blog should be able to question the validity of the old blog as such: the new blog contains a findmeon for the old blog with the command expired along with timestamp Readers that encounter that tag should check to see if both resources are verifiable with the same public key. If they are, the expired item should drop to VERIFIED- status, as if the signature was 1 year old. The same mechanism should be used for exipring attributes/subtypes of a findmeon that is replaced with updated information. (For example, migrating a personal email to a business email) Another special case is when someone alleges ownership of an item you control. There are several mechanisms to handle that If the other person has put a findmeon on that page, use the same key to: sign a findmeon for the disputed resource sign a node that says "refute" along with the signature of the other person's key In that scenario, the item should have ALLEGED- status. or if the other person just has a 'SeeAlso' linking to your page... Sign the resource with the 'Special' attribute of 'Require:findmeon' Require:findmeon should instruct all indexers to ignore SeeAlsos that point to your resource unless they can verify both tags with the same key. ie: instead of receiving an ALLEGED status, the SeeAlso should be an ALLEGED- status. Important Note the current signing/validating is as such: sign( private_key , digest(asserted) ); verify( public_key , signature , digest(asserted) ) With that in mind: if 'asserted' is a single value in a findmeon tag: asserted= the contents of the value="CONTENTS" if 'asserted' is a tag tree in a findmeon tag: asserted= the contents INCLUDING WHITESPACE of the CONTENTS the reason for this is simple: its easier/more standard results to digest(regex(asserted)) than digest(xmlparse(asserted)) Digest and Encryption Digest and Encryption are specified for the .09 version of findmeon as such: Digest: SHA-1 digest method. SHA-1 is available in all languages , including javascript Encryption: RSA 1024 Transport: RSA keys should be 1024 bits long, encoded in the DER format, and use PKCS1 padding PKCS1 / RSA 1024-SHA1 is used as the default specification because performance fits the 'sign once, verify many' constraint - it is expensive to sign but trivial to verify. DSA, while more secure, is computationally trivial to sign a document but expensive to verify. An alternate DSA specification ( 0.09-DSA ) MAY be introduced. Hard-coding the encryption option in the specification was a design choice, in order to streamline the node content and size. Verification and Indexing of FindMeOn nodes STATUS CODES There are several status levels for FindMeOn items that readers and indexers should respect VERIFIED : The item has been alleged and validated using the public key with a timestamp within the last 1 year. VERIFIED- : The item was alleged and validated using the public key with a timestamp older than the last year. ALLEGED : The item was alleged in a SeeAlso tag by another FindMeOn ALLEGED- : The item was signed by a compromised key, or alleged in a SeeAlso tag signed by a compromised key. If a FindMeOn node is indexed, Items listed in the 'see also' section should be considered ALLEGED links unless they contain a FindMeOn signature that can be verified using the same public key. If a FindMeOn node references a Foaf/XFN document, all entries contained therein should be considered ALLEGED unless they contain a FindMeOn signature that can be verified using the same public key. A reasonable attempt should be made to test for key validity-- a simple google search should suffice, but it would be prudent to check any SeeAlso items listed against that findmeon for a reference to the key's status. If a key has been compromised, anything signed with it should be considered ALLEGED-. Notice there is an ALLEGED and ALLEGED-. ALLEGED- means there is stigma associated with the key, and a greater chance that the allegation is wrong. Footnotes: FOAF document refers to an RDF document formatted to the FOAF specification XFN document refers to a (X)HTML page that contains XFN data Capitalization Notice: FindMeOn - refers to FindMeOn.com findmeon - refers to the open standard Intellectual Property Notice The findmeon standard is essentially an abstracted, encapsulated and timestamped version of conventional message and document signing methods. As such it shouldn't be privy to any sort of patent -- and if it were, FindMeOn.com has nullified any claims from itself to exclusive use of the idea by publishing it as an open standard. References: XML-Signature Syntax and Processing https://www.w3.org/TR/xmldsig-core/ Digital Signature - Signed PICS labels (DSig 1.0) https://www.w3.org/DSig/ W3 Signature https://www.w3.org/Signature/ OpenID https://openid.org Copyright & Licensing: (c) copyright 2006-2019 FindMeOn, Inc / Jonathan Vanasco (jvanasco@FindMeOn.com) FindMeOn® is a registered trademark of FindMeOn inc. All Rights Reserved This work is licensed under the Creative Commons Attribution-No Derivative Works 2.5 License. To view a copy of this license, visit https://creativecommons.org/licenses/by-nd/2.5/ or send a letter to Creative Commons, 543 Howard Street, 5th Floor, San Francisco, California, 94105, USA.