CLAIM REQUEST: verification-methods

[Denise Tayloe]

The verification-methods claim, defined at https://informationcard.net/wiki/index.php/Claim_Catalog, provides relying parties information about the methods used to verify the claims in the verified-claims list.  This is needed for Privo's parent cards and compatible cards.

 

 

Thanks,

Denise

 

 

Denise G. Tayloe, CEO

Privacy Vaults Online, Inc. d/b/a/ Privo

dta...@privo.com

703-932-4979

703-783-8752 fax

www.privo.com

 

Children's Identity and Parental Permission Management

 

This communication may contain privileged or confidential information.

If you are not the intended recipient of this communication, please advise the sender immediately and delete this message.

 

[Mike Jones]

+1

[John Bradley]

You have Email+ listed as a value.  Should that be Email,  or Email+Link to be consistent with the other two?

If that is clarified then +1

=jbradley

[Denise Tayloe]

Please take a look at the wiki as email+ is defined in its simplest form.

Email verification would technically be email plus link.

Email+ verification would equal email verification plus confirmation email notice and opt out

Email plus another confirmation method would be email verification plus email confirmation notice and opt out PLUS method (example post card, phone call, sms etc.)

So I believe that email+ should be left as is otherwise we would have to say email+email+SMS OR +mail etc.

Denise

________________________________

[Axel Nennker]

Why don't we reuse the age18-or-over claim for this?
I think that we should use age18-or-over and a new age18-or-over-
verification-method claim to do the COPPA business.
If several methods were used then there are multiple occurences of
this claim in the security token.

I am very much against "Space-separated list of "-anything. Actually I
am against two things in regard with the proposed "verification-
methods/2008-12" claim.
First the "space-separated"-list but then the values of that list
should be tokens instead of strings.

Is the verification-method used by Equifax covered by the proposed
list of verification methods?

-1

Axel

On 13 Dez., 06:02, "Denise Tayloe" <dtay...@privo.com> wrote:
> The verification-methods claim, defined athttps://informationcard.net/wiki/index.php/Claim_Catalog, provides

> relying parties information about the methods used to verify the claims
> in the verified-claims list.  This is needed for Privo's parent cards
> and compatible cards.
>
> Thanks,
>
> Denise
>
> Denise G. Tayloe, CEO
>
> Privacy Vaults Online, Inc. d/b/a/ Privo
>

> dtay...@privo.com

[Denise Tayloe]

The coppa certified adult does use the 18 and over claim. It requires a relevant verification method that can be used in a sliding scale regulatory environment. If a provider makes a coppa verified claim which equifax could then they need to call out the verification method in order for the relying party to apply the coppa verified claim to the sliding scale for coppa verification level required. In equifax case I would look for a method KBA.

What I really want to get approved is the individual verification methods as stand alone methods so the relying party can mix and match to their own needs.

if your token comment means we would issue a token with multiple claims and not load up the verification method claim in a string then I am ok with that. But I want Mike to weigh in as I am business vs technical on this issue.

MIKE -- please weigh in as this may be slightly different then the way it is described on the wiki.

[Axel Nennker]

Is coppa-certified-adult equivalent to age18-or-over plus one-or-more-
coppa-accepted-verifaction-method ?
If yes, then we don't need the coppa-certified-adult, right?

>  winmail.dat
> 5KAnzeigenHerunterladen

[Denise Tayloe]

Not really
A coppa verified adult has to be 18 and over through some level of verification. However they are also asserting themselves as an adult who is asserting a custodian relationship over a child. Can fall into parent, teacher and or guardian relationship. In our case they have to sign off on TOU and PP and acknowledge that using this credential requires them to understand the you and pp of the relying party as it relates to the collection, use or disclosure of a childs data.

[Mike Jones]

Denise and I just spoke. She's ok with changing verification-methods to verification-method (not a list) and having the value of that claim be a URI. So we'll define some verification-method URIs.

Also, addressing John's issue with the "email+" name, we'll make it more clear in the URIs what the actual method is.

Expect updates to the wiki and follow-up e-mail in the next 24 hours. Thanks for all of your helpful input.

-- Mike

-----Original Message-----
From: icf-wg-...@googlegroups.com [mailto:icf-wg-...@googlegroups.com] On Behalf Of Denise Tayloe

[Mike Jones]

OK -- these changes are now reflected on the wiki. I believe they address the issues raised by both John and Axel. Consider Denise's verification-methods request withdrawn and instead let's have a vote on the new verification-method claim and associated verification method URIs listed at https://informationcard.net/wiki/index.php/Claim_Catalog#Verification_Methods.

I vote +1.

Axel, can you now also change your vote to +1?

Thanks all for the useful feedback on these claims.

[Paul Trevithick]

According to our current process (see [1]), we distinguish between a “CLAIM-REQUEST” email that begins a discussion period. And a CLAIM-VOTE email that initiates the 7 day voting period.

I have edited [1] to include the ability to vote for “approved” or “provisional” status based on our telephone meeting last week.

[I also noticed that the two previous claims, us-resident and us-registered-voter have not been voted on. I’ll send out an email now for those two].

--Paul

[1] https://informationcard.net/wiki/index.php/Adding_to_the_Claim_Catalog#Approval_Process

[Mike Jones]

Thanks for the clarification Paul.  Both of Denise’s messages were intended to initiate VOTING, as was mine that was apparently erroneously labeled CLAIM REQUEST rather than CLAIM VOTE.  I assume that we can let the votes that were already registered for the COPPA-certified-adult stand, because that was the intent of the message.

 

For the record, I (again) vote +1 for the verification-method claim.

 

                                                                -- Mike

[Axel Nennker]

+1

On 15 Dez., 05:15, Mike Jones <Michael.Jo...@microsoft.com> wrote:
> Thanks for the clarification Paul.  Both of Denise's messages were intended to initiate VOTING, as was mine that was apparently erroneously labeled CLAIM REQUEST rather than CLAIM VOTE.  I assume that we can let the votes that were already registered for the COPPA-certified-adult stand, because that was the intent of the message.
>
> For the record, I (again) vote +1 for the verification-method claim.
>
>                                                                 -- Mike
>
> From: icf-wg-...@googlegroups.com [mailto:icf-wg-...@googlegroups.com] On Behalf Of Paul Trevithick
> Sent: Sunday, December 14, 2008 5:40 PM
> To: ICF.WG.Schemas
> Subject: [ICF.WG.Schemas] Re: CLAIM REQUEST: verification-method
>
> According to our current process (see [1]), we distinguish between a "CLAIM-REQUEST" email that begins a discussion period. And a CLAIM-VOTE email that initiates the 7 day voting period.
>
> I have edited [1] to include the ability to vote for "approved" or "provisional" status based on our telephone meeting last week.
>
> [I also noticed that the two previous claims, us-resident and us-registered-voter have not been voted on. I'll send out an email now for those two].
>
> --Paul
>

> [1]https://informationcard.net/wiki/index.php/Adding_to_the_Claim_Catalo...
>
> On 12/14/08 6:17 PM, "Mike Jones" <Michael.Jo...@microsoft.com> wrote:
> OK -- these changes are now reflected on the wiki.  I believe they address the issues raised by both John and Axel.  Consider Denise's verification-methods request withdrawn and instead let's have a vote on the new verification-method claim and associated verification method URIs listed athttps://informationcard.net/wiki/index.php/Claim_Catalog#Verification....

[Ian Hummel]

+1

[John Bradley]

+1

[Paul Trevithick]

+1 for “approved” (not for provisional) status. I’m going to assume that all the other +1s are also for “approved”

On 12/15/08 8:52 AM, "Ian Hummel" <themod...@gmail.com> wrote:

+1

On Mon, Dec 15, 2008 at 3:24 AM, Axel Nennker <ignis...@googlemail.com> wrote:

+1

On 15 Dez., 05:15, Mike Jones <Michael.Jo...@microsoft.com> wrote:
> Thanks for the clarification Paul.  Both of Denise's messages were intended to initiate VOTING, as was mine that was apparently erroneously labeled CLAIM REQUEST rather than CLAIM VOTE.  I assume that we can let the votes that were already registered for the COPPA-certified-adult stand, because that was the intent of the message.
>
> For the record, I (again) vote +1 for the verification-method claim.
>
>                                                                 -- Mike
>
> From: icf-wg-...@googlegroups.com [mailto:icf-wg-...@googlegroups.com] On Behalf Of Paul Trevithick
> Sent: Sunday, December 14, 2008 5:40 PM
> To: ICF.WG.Schemas
> Subject: [ICF.WG.Schemas] Re: CLAIM REQUEST: verification-method
>
> According to our current process (see [1]), we distinguish between a "CLAIM-REQUEST" email that begins a discussion period. And a CLAIM-VOTE email that initiates the 7 day voting period.
>
> I have edited [1] to include the ability to vote for "approved" or "provisional" status based on our telephone meeting last week.
>
> [I also noticed that the two previous claims, us-resident and us-registered-voter have not been voted on. I'll send out an email now for those two].
>
> --Paul
>
> [1]https://informationcard.net/wiki/index.php/Adding_to_the_Claim_Catalo...
>
> On 12/14/08 6:17 PM, "Mike Jones" <Michael.Jo...@microsoft.com> wrote:

> OK -- these changes are now reflected on the wiki.  I believe they address the issues raised by both John and Axel.  Consider Denise's verification-methods request withdrawn and instead let's have a vote on the new verification-method claim and associated verification method URIs listed athttps://informationcard.net/wiki/index.php/Claim_Catalog#Verification.. <http://informationcard.net/wiki/index.php/Claim_Catalog#Verification..> ..

> > > The verification-methods claim, defined athttps://informationcard.net/wiki/index.php/Claim_Catalog <http://informationcard.net/wiki/index.php/Claim_Catalog> , provides

> > > relying parties information about the methods used to verify the claims
> > > in the verified-claims list.  This is needed for Privo's parent cards
> > > and compatible cards.
>
> > > Thanks,
>
> > > Denise
>
> > > Denise G. Tayloe, CEO
>
> > > Privacy Vaults Online, Inc. d/b/a/ Privo
>
> > > dtay...@privo.com
>
> > > 703-932-4979
>
> > > 703-783-8752 fax
>

> > >www.privo.com <http://www.privo.com>

[Drummond Reed]

ABNF cop here again ;-)

 

Although the proposed claim itself is syntactically valid per the ABNF we defined at https://informationcard.net/wiki/index.php/Claim_URI_Syntax, one of the claim values proposed at https://informationcard.net/wiki/index.php/Claim_Catalog#Verification_Methods is not.

 

The fourth entry in the table uses a + sign:

 

            email-verification+email/2008-12

 

To maximize interoperability, we specified only one word separator – a hyphen. Therefore to be syntactically valid this claim value would need to be revised to:

 

            email-verification-email/2008-12

 

(Ironically, while it seems redundant, I find it no less confusing that the previous form, which already appears confusing to the average reader, and it only uses our one standard word separator.)

 

My vote is +1 if this change is made, -1 if it is not.

 

=Drummond

 

 

---

[Mike Jones]

Hi Drummond,

 

I’m going to push back on this one and ask you to change your vote on this one, because the “+” is both a valid URI character and is being intentionally used to convey meaningful information about the nature of the method.  Specifically, this method actually consists of two actions – an e-mail verification and then a follow-up e-mail later.  That’s why the actions are separated by a “+” rather than a “-”.

 

Talking with Denise, we expect there to be additional “combination” methods in the future, that we would also want to use the “+” separator to indicate this fact.  You could imagine, for instance, combination methods like:

                email-verification+knowledge-based-authentication

                email-text-msg+in-person-proofing

etc.

 

Replacing the “+” with a “-” would lose this semantic distinction.

 

Finally, I’ll add that we changed from having a verification-methods claim with a space-separated list of methods to a verification-method claim at Axel’s request.  But that doesn’t remove the need to sometimes express that the “method” may actually be a combination of methods.

 

Can you change your vote to a +1 in this case on that basis?

 

                                                                Thanks,

                                                                -- Mike

[John Bradley]

I just went back and looked at the URI for the verification methods.

The only one with a + is email-verification+email the other cases
where the user is sent an email and confirms with SMS or something
else use a -.

I am not seeing a clear explanation of the syntactic significance of
the +. At-least not in the existing set of URI.

To be consistent it should be email-verification-email then you can
say email-verification-email+in-person-proofing or email-verification-
text-msg+in-person-proofing.

So to be consistent if + indicates a combination of two verification
methods then it has to be email-verification-email as that is a singe
verification method.

I am not certain that defining 30 or so URI for every combination of
verification type is the correct thing to do ether.

I agree with Axel that the verification methods should be URI but a
list of the verification types seems more useful than trying to cram
them all into a single URI.

=jbradley

[Drummond Reed]

Mike and everyone,

 

I think I understand what you’re saying here but there’s a larger issue behind it that’s important enough that it’s worth explaining in more detail.

 

***** RATIONALE FOR CLAIM URI SYNTAX *****

 

When we designed the claim URI syntax at https://informationcard.net/wiki/index.php/Claim_URI_Syntax, we intentionally made it very restrictive. I’m reproducing it here for simplicity:

 

  icf-claim-type-uri   = "http://schemas.informationcard.net/@ics/" claim-name "/" version

  claim-name           = claim-word *( "-" claim-word )

  claim-word           = 1*( lower-alpha / DIGIT )

  lower-alpha          = %x61-7A      ; a-z

  version              = year "-" month       ; version identifier

  year                 = 4DIGIT

  month                = 2DIGIT

 

 

The concept was that claim names would only be expressed as a series of claim words separated by hyphens, and claim words could only contain lowercase letters and digits.

 

The reason we made it so restrictive is that experience on the OASIS XRI TC has taught those of us in XRI land that URI comparison in the many different environments in which a URI may be used is much more fraught with difficulties than most folks realize. First there’s case sensitivity/case folding, which is always a nightmare. We avoid that completely by: a) restricting the character set to digits plus alpha letters, and b) restricting the alpha letters to lowercase.

 

The other nightmare is delimiters. For example, as you point out, + is a valid URI character, however when it appears in the query portion of a URI some web servers/CGI processors treat it specially. For example, because + is often used to replace spaces in a filename when it is converted into a URL, some processors automatically replace + with a space. Other processors automatically percent-encode it (or automatically un-percent-encode it).

 

The same can be true to a lesser or greater extent of almost all the delimiter other characters in the URI syntax (http://www.ietf.org/rfc/rfc3986.txt, Appendix A). The relevant portion of that syntax is:

 

   unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~"

   reserved      = gen-delims / sub-delims

   gen-delims    = ":" / "/" / "?" / "#" / "[" / "]" / "@"

   sub-delims    = "!" / "$" / "&" / "'" / "(" / ")"

                 / "*" / "+" / "," / ";" / "="

The XRI TC’s experience is that if you want to avoid issues in URI comparison, the best thing to do is steer clear of all characters in the “reserved” set except those that you absolutely need to create the URI. (XRIs use many of these delimiters in XRI syntax because we have too, which is why we’re so familiar with these issues).

 

If you follow that rule, then the “safe” punctuation characters you’re left with are the unreserved chars:

 

   unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~"

 

Of those, the W3C advises NOT using underscores in URIs because when the URI itself is underlined (as a link), they can appear as spaces. And tilde (~) is generally avoided because it can be hard to distinguish from a hyphen at small point sizes.

 

Which leaves hyphens and dots.

 

Since dots are smaller visually and also used as delimiters in certain circumstances (domain names), the safest punctuation character to use for visual separation of words in a URI is a hyphen. Since ICF is minting all ICF-based claim URIs from scratch (a rare opportunity to “do it right”), that’s why we restricted the syntax to use hyphens. (However if anyone wants to propose adding dots as another supported claim word-separator, I’m fine with that).

 

*******

 

Returning to the claims at hand, using just hyphens is not actually much of a “restriction” – it just means that rather than using punctuation characters, you express semantics by “spelling things out” using hyphen-separated-words. For example, the semantics I think you are seeking in your message below could be expressed as:

 

                email-verification-by-email

                email-verification-by-knowledge-based-authentication

                email-text-msg-by-in-person-proofing

 

I think those strings are more readable than any of the proposals so far, and I would gladly vote +1 for all of them.

 

Hope this helps,

[Mike Jones]

OK, taking Drummond’s suggestion, let’s change email-verification+email to email-verification-then-email.  Drummond, I assume you’re a +1 at that point, given your statement below.  I’ve made these changes on the wiki.

 

                                                                Thanks all,

[John Bradley]

Just for clarification, are we now abandoning creating new claim URI values by concatenating combinations of verification types like: 

http://schemas.informationcard.net/@ics/verification-method/email-verification-email+in-person-proofing/2008-12 

Or is that still the plan without the + ?

I am not opposed to a space separated list of URI as the value of verification-method/2008-12 

I think that is preferable to minting a large number of URI for the value to represent every possible combination.

=jbradley

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "ICF-WG-Schemas" group. 
To post to this group, send email to icf-wg-...@googlegroups.com 
To unsubscribe from this group, send email to icf-wg-schema...@googlegroups.com 
For more options, visit this group at http://groups.google.com/group/icf-wg-schemas?hl=en
-~----------~----~----~----~------~----~------~--~---

[Mike Jones]

I believe that Denise would ultimate be happier if we went back to a “verification-methods” claim with the value being a space-separated list of URIs for individual methods.  The problem then though, would become one of interpretation.  If I specify multiple methods, does it mean that I applied all those methods to all the verified claims or that at least one of those methods was applied to each of the verified claims?  Because there isn’t a clear-cut answer to that question (although I suspect it would be the latter), it seemed simpler not to go there (for now).

 

                                                                -- Mike

[Drummond Reed]

Thanks Mike. To be explicit for the record, +1 to what’s now on the wiki.

[John Bradley]

So that is a good question.  The old meta claim problem rises again.

When the http://schemas.informationcard.net/@ics/verification-method/2008-12 is included in a claim set is it intended to apply to all the other claims in the set?

That is the to what other claim does this metta claim apply problem.

However isn't that a separate issue from wanting to say that you verified the person two or more different ways?

Ideally Denise would probably like to say by what method or methods were each of the claims verified.

If that list included unverified that could loose the verified-claims/2008-11 claim.

One is tempted to think of changing verified-claims/2008-11 to be a array of claims and there verification methods.

It is getting close to crating a new token to pass in the value of the claim.

Without more clarification I could only take the value of http://schemas.informationcard.net/@ics/verification-method/2008-12 as applying to all the claims on the  token.   Or is there some implicit rule that it only applies to claim URI listed in verified-claims/2008-11,  and that any claim that is not listed in verified-claims/2008-11 should be considered self asserted?

If the verification method needs to be understood in the context of verified-claims/2008-11 we need to say that someplace.

=jbradley

[Charles Andres]

+1.

This is the same restriction for Internet domain names, (at least that
was the case in 1997) Use ' - ' only for delimiters.

Charles Andres, Executive Director
Information Card Foundation
56 Kearney Road
Needham, MA 02494 USA
781 559 4223
can...@informationcard.net

[Drummond Reed]

[changed subject line to bring up a related topic]

 

As Mike’s email below illustrates, the more claims we develop, the more issues I think will come up with a “flat” URI claimspace. Don’t get me wrong – starting with flat name/value pairs (where the name is a URI) is a great way to KISS at this early stage so real RPs can start using real claims real soon.

 

But in the long run it’s analogous to restricting all questions in the English language to multiple-choice answers ;-)

 

At a certain point the need for “semantic claims” will reach critical mass. By semantic claims I’m talking about claims that are not just flat name/value pairs, but RDF statements.

 

Before anyone starts throwing brickbats, I’m not suggesting anything as complex as RDF XML. I’m thinking about XDI RDF statements, since they are much simpler and in most cases can be serialized as URIs. Here’s a simple example. Take the following two ICF claim URIs we have defined:

 

            http://schemas.informationcard.net/@ics/age-18-or-over/2008-11

            http://schemas.informationcard.net/@ics/verification-method/2008-12

 

The problem we are trying to solve is how can an RP ask not just for one general verification method for all claims, but for the specific verification method used for each specific claim. If we needed to define each combination using ordinary URI syntax, this would quickly lead to a combinatorial explosion.

 

One solution might be to allow attributes on claims. But attributes get sticky very fast. To begin with, attributes are QNames, so only one authority can define the QNamespace for any primary claim. Secondly, attributes have a more restrictive value space than claims. Thirdly, while attributes move us from a flat name/value space to a two-dimensional claimspace, they stop there. What about three-dimensionnal (attributes on attributes)? It’s a lot more common than you might think.

 

With XDI RDF, you can express simple combinations of claims very easily, even if those claims are already expressed with URIs. The steps are:

 

            1) Turn each claim URI into a self-referential XRI using the algorithm xri=$(uri). For example

 

                        http://schemas.informationcard.net/@ics/age-18-or-over/2008-11

 

            becomes

 

                        $(http://schemas.informationcard.net/@ics/age-18-or-over/2008-11)

 

            2) Combine the XRIs in contextual order (highest to lowest precedence of context) using concatenation. (Note: the URIs above are too long to make this easy to view, so in the following examples I shortened the domain name to “icf.org”.)

 

            $(http://icf.org/@ics/age-18-or-over/2008-11)$(http://icf.org/@ics/verification-method/2008-12)

 

This is now the XRI identifying the verification method used for the age-18-or-over claim. Note that technically it’s a relative URI. If it’s necessary to turn it into an absolute URI, add a URI scheme prefix (this is new in XRI 3.0). For example:

 

            http://xri.net/$(http://icf.org/@ics/age-18-or-over/2008-11)$(http://icf.org/@ics/verification-method/2008-12)

 

The nice thing is that this pattern works for any combination of claim URIs, from any authority, to any dimension (two, three, four, etc.)

 

Anyway, it’s just a thought I wanted to plant now – the XDI 1.0 specs won’t be out until next spring so it’s not feasible in the current generation of information cards anyway. But for the next generation we really ought to think about it.

 

=Drummond

(full disclaimer of bias – co-chair of OASIS XDI TC ;-)

[John Bradley]

Yes this is an interesting way to perhaps express semantic meaning in claim URI.

It however doesn't solve the problem of creating a UI that would package together sets of optional claims that would need to be delivered together.

Saying I need the age-over18 claim with its verification method or the age-over21 claim with its verification method is a hard thing to do.

=jbradley

[Castilon, Karen]

Hi all.

 

I am Denise’s product manager at Privo, and I just wanted to let everyone know that we intend to launch our Information Card solution with the claims and verification methods as they are currently defined on the wiki.

 

For clarity’s sake, we would prefer to identify what method was used to identify each claim, but since that will definitely become much more complicated, we are indicating that only the claims listed in the verified claims value list were verified and that at least one of the listed verification methods was applied to each of the listed verified claims.

 

Thanks so much.

 

Karen

[John Bradley]

At the moment there is only one verification method URI allowed to be
returned as the value of http://schemas.informationcard.net/@ics/verification-method/2008-12
. So there is no way to express multiple authentication methods
unless you create a grammar for encoding them into the single URI
response.

Otherwise this needs to be changed to return a list of URI like
verified-claims/2008-11.

I don't see that described with sufficient precision that some one
else could safely re-use this.

Someplace it needs to say that this meta-claim applies to all the
claim URI that are returned in the Value of verified-claims/2008-11.

I am OK with these as provisional, however the precision of the use
needs to be cleaned up so they can be used by people other than Privo.

=jbradley

> +email to email-verification-then-email. Drummond, I assume you’re

> #Verification_Methods is not.

>
> The fourth entry in the table uses a + sign:
>
> email-verification+email/2008-12
>
> To maximize interoperability, we specified only one word separator –
> a hyphen. Therefore to be syntactically valid this claim value would
> need to be revised to:
>
> email-verification-email/2008-12
>
> (Ironically, while it seems redundant, I find it no less confusing
> that the previous form, which already appears confusing to the
> average reader, and it only uses our one standard word separator.)
>
> My vote is +1 if this change is made, -1 if it is not.
>
> =Drummond
>
>

[Castilon, Karen]

Sorry if I’ve caused any confusion with my note below.  The values for the verification method claim are defined on the wiki as plan to use them.

 

We realize we can only display one verification method at this time.

 

Thanks.

 

Karen

[John Bradley]

So lets see if I have this correct.

https://informationcard.net/wiki/index.php/Claim_Catalog#New_Requests

We have three levels of claims.

1: Primary claims such as http://schemas.informationcard.net/@ics/coppa-certified-adult/2008-12 this is tri-boolean on the surface clear.

2: Meta claims like http://schemas.informationcard.net/@ics/verified-claims/2008-11 that contain a list of claim URI that they apply to.  Effectively used in place of a claim attribute.   If this appears in the same card as 1 and the URI from 1 is not included then 1 must be understood as self asserted.

3: Meta-Meta claims like http://schemas.informationcard.net/@ics/verification-method/2008-12 that provide additional information about Meta claims.

If 3 appears without 2 then the meaning of 3 is undefined?  

If it appears with 1 and 2 and 2 includes the URI of 1 and 3's value is http://schemas.informationcard.net/@ics/verification-method/ssn4/2008-12 http://schemas.informationcard.net/@ics/verification-method/ssn4/2008-12 

Then we know that the subject of the card is a copa-certified adult that has been verified by checking there SSN!   

Seems simple:)

My question is simply what tells you in the Meta-Meta claim what Meta claim it applies to.

I see the clear relationship between the claim and the meta claim.

Without insider knowledge I don't think this can be deciphered by a third party to re-use this claim.

What am I not understanding here?   Is this a model that we should be following in general?

I don't want to hold this up,  but I do want to understand where we are headed with these meta caims.

=jbradley

[Mike Jones]

I thought this was already clear because of this sentence in the definition of verification-method:

                The verification method claim provides a URI representing the verification method employed for verifying the verified claims.

 

Would it satisfy you if we made this sentence even more explicit in this manner?

                The verification method claim provides a URI representing the verification method employed for verifying the verified claims listed in the verified-claims claim.

 

                                                                -- Mike

[John Bradley]

Mike,

There is no guarantee that over time the claims will stay together in the dictionary,  so what may be an obvious inference now may not be in the future once there are other claims like the age-18-or over claim.

As that is in principle a verified claim someone could misinterpret the verification-method as applying to it without the presence of verified-claims/2008-11.

I would be happier if the description of verified claims makes it clear that it refers to the claims listed as the values of verified-claims/2008-11 .

I personally think that verified-claims/2008-11 would be more useful if it were defined to be a list of URI rather than a single one.

However if there is no need to ever list more than a single verification method per set of claims I can live with it.

If the intent is to come back and define some large number of URI to describe every possible combination I will not be a happy camper.

I still find this funky.  I hope we can come up with a better way to do this in the future.

=jbradley

[Mike Jones]

The sentence has been augmented to read “The verification method claim provides a URI representing the verification method employed for verifying the verified claims enumerated in the verified-claims/2008-11 claim” to make the relationship between the two claims explicit, per your suggestion.

 

Have a good weekend!

 

                                                                -- Mike

 

From: John Bradley [mailto:john.b...@wingaa.com]
Sent: Friday, December 19, 2008 2:43 PM
To: Mike Jones
Cc: icf-wg-...@googlegroups.com
Subject: Re: [ICF.WG.Schemas] Re: CLAIM VOTE: verification-method

 

Mike,

 

There is no guarantee that over time the claims will stay together in the dictionary,  so what may be an obvious inference now may not be in the future once there are other claims like the age-18-or over claim.

 

As that is in principle a verified claim someone could misinterpret the verification-method as applying to it without the presence of verified-claims/2008-11.

 

I would be happier if the description of verified claims makes it clear that it refers to the claims listed as the values of verified-claims/2008-11 .

 

I personally think that verified-claims/2008-11 would be more useful if it were defined to be a list of URI rather than a single one.

However if there is no need to ever list more than a single verification method per set of claims I can live with it.

 

If the intent is to come back and define some large number of URI to describe every possible combination I will not be a happy camper.

 

I still find this funky.  I hope we can come up with a better way to do this in the future.

 

=jbradley

 

On 19-Dec-08, at 5:59 PM, Mike Jones wrote:

I thought this was already clear because of this sentence in the definition of verification-method:

                The verification method claim provides a URI representing the verification method employed for verifying the verified claims.

 

Would it satisfy you if we made this sentence even more explicit in this manner?

                The verification method claim provides a URI representing the verification method employed for verifying the verified claims listed in the verified-claims claim.

 

                                                                -- Mike

style='color:black'>

 

 

[John Bradley]

I am off to go hiking in the Andes tomorrow.

+1 for provisional then.

[Mike Jones]

This isn’t a vote for provisional.  This is a vote for approved, because this is going into production any day now.  I hope you’ll vote for approval outright, given this claim provides business value in a real scenario, and is now clearly enough defined.

 

Provisional is only appropriate for claims that are not yet going into production, at least as I understood the discussion on the last call.

 

Enjoy the Andes!

[John Bradley]

Sorry the Voting ones were provisional my mistake.

+1 for approval now.

=jbradley

[Denise Tayloe]

Thanks John

Mike -- can we please talk sometime this weekend?

I couldn't make it home last night so I will be west coast until they get me out on Sunday at 1pm.

D

________________________________

[Paul Trevithick]

More than three +1, zero –1s.

The proposal was altered slightly during the voting process. Speak up if you object to the above characterization of the vote.

To reduce this kind of confusion in the future, let’s try to have our discussions before the CLAIM-VOTE email (i.e. let’s have the discussion in the CLAIM-REQUEST email thread not the –VOTE thread).

--Paul



On 12/13/08 12:02 AM, "Denise Tayloe" <dta...@privo.com> wrote:

The verification-methods claim, defined at https://informationcard.net/wiki/index.php/Claim_Catalog, provides relying parties information about the methods used to verify the claims in the verified-claims list.  This is needed for Privo's parent cards and compatible cards.

 
Thanks,
Denise
 
 

Denise G. Tayloe, CEO
Privacy Vaults Online, Inc. d/b/a/ Privo

dta...@privo.com

703-932-4979
703-783-8752 fax
www.privo.com <http://www.privo.com>  
 

[PaulT]

Typo correction: I meant: "More than three +1s, zero -1s.

On Dec 22 2008, 4:30 pm, Paul Trevithick <ptrevith...@gmail.com>
wrote:

> More than three +1, zero ­1s.
>
> The proposal was altered slightly during the voting process. Speak up if you
> object to the above characterization of the vote.
>
> To reduce this kind of confusion in the future, let¹s try to have our
> discussions before the CLAIM-VOTE email (i.e. let¹s have the discussion in
> the CLAIM-REQUEST email thread not the ­VOTE thread).
>
> --Paul
>

> On 12/13/08 12:02 AM, "Denise Tayloe" <dtay...@privo.com> wrote:> The verification-methods claim, defined at

> >https://informationcard.net/wiki/index.php/Claim_Catalog, provides relying
> > parties information about the methods used to verify the claims in the
> > verified-claims list.  This is needed for Privo's parent cards and compatible
> > cards.
>
> > Thanks,
> > Denise
>
> > Denise G. Tayloe, CEO
> > Privacy Vaults Online, Inc. d/b/a/ Privo

> > dtay...@privo.com