CLAIM VOTE (provisional) username & password

[Paul Trevithick]

Per our process [1], this email is to call for a vote on the proposed username and password claims here [2].

On this list and on our calls we have had discussions related to these pair of claims. Topics have included:

• How these claims could be requested by Information Card compatible proxy servers or by form filling “password manager” browser extensions acting as an RP (from the selector’s POV)
• How they should be used such that the values returned by selectors are site/app-dependent and further that the password values are different for each site or app to encourage the highest security. In some use cases this requires the RP passing a URL of the un/pw login form to the selector as a parameter, and there is no general agreement on the best way to do this.
• How selectors and password manager plugins need to exercise special care to prevent phishing attacks. It isn’t entirely clear how best to do this as it usually involves authentication of the password manager to the selector and the mechanisms for doing this (e.g. The browser plugin having its own cert, etc.) are not yet clear.
  

Despite the controversy swirling around the outside, there remains the need for username and password claims. In recognition of the surrounding uncertainty, I propose that these two be voted as “provisional”--thus allowing us to update the descriptive text based on what we learn as we implement systems that use them. The Higgins project, for example, has a Password Cards [3] project that needs these claims at the least.

My vote is +1. (We are voting here for “username” and “password” simultaneously).

--Paul

[1] https://informationcard.net/wiki/index.php/Adding_to_the_Claim_Catalog#How_to_Make_a_Request
[2] https://informationcard.net/wiki/index.php/Claim_Catalog
[3] http://wiki.eclipse.org/Password_Cards

[John Bradley]

I am hesitant to make these clams part of the set that normal RP's might use.

These really are for a local client to use with a selector doing something outside the existing information card specification.

I understand the Higgins desire to create an password card standard.  

However Higgins is a Open Source project and not a SDO,  I am unsure of the IPR generated there.   I am certain that you or Marry can answer that question.

These claims require some new selector functionality.  I would like to see IPR guarantees on that work before the claims become part of the ICF information-card claims.

I would have less of a problem if we had a separate namespace for vendor proposals that may be on a standards trac, but wanted someplace to document themselves.

I think these claims are qualitatively different from the other ones we have discussed. 

I will be hard pressed to vote in favor of this.

However I want to hear other peoples opinions before I make a final decision on this.

John B.

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

[Paul Trevithick]

## inline

On 4/8/09 2:11 AM, "John Bradley" <ve7...@ve7jtb.com> wrote:

I am hesitant to make these clams part of the set that normal RP's might use.

## defining normal will be hard :)

These really are for a local client to use with a selector doing something outside the existing information card specification.

## sounds like you’re suggesting that the ICF Schemas WG should only propose claims that are compatible with existing specifications. This is a bad idea because we’ll be right back where we were with folks making up claims in their own private namespaces. I (and IBM) lobbied Kim hard to move the original p-card claims from a Microsoft namespace to the current xmlsoap namespace and Microsoft graciously did so even at the cost of interop problems in the field for a time.

## It is better to be “proactive” about working towards claims interop. The cost of standardizing on some common claims that end up never being used is nearly zero. The cost of not standardizing on some claims that become established is enormous. To give an example, we all knew that the only way to handle the existing 14 p-card claims was to “grandfather them” by calling them “well known claims.” The cost to make them “ICF-defined” claims is a million times the benefit at this point.

I understand the Higgins desire to create an password card standard.  

## No, Higgins just wants to make something that leverages i-card infrastructure, UX, etc. and works no worse than the 50 or so password managers out there in the market.

However Higgins is a Open Source project and not a SDO,  I am unsure of the IPR generated there.   I am certain that you or Marry can answer that question.

## Higgins is not an SDO and this is the very reason that it would RATHER NOT use the eclipse higgins namespace for these claims. [Though I think this is where we’re headed since nobody is voting in favor here]

These claims require some new selector functionality.  I would like to see IPR guarantees on that work before the claims become part of the ICF information-card claims.

## Any code developed under the EPL falls under the EPL’s rather mature IPR regime (including patents). It is similar to the Apache 2.0 license if you’re familiar with that.

I would have less of a problem if we had a separate namespace for vendor proposals that may be on a standards trac, but wanted someplace to document themselves.

## I think what you propose here is a good fallback that may be acceptable to many on the Schemas group. This is effectively what we’ve done with the “well known claims” section of the claims catalog. These are claims that the ICF didn’t define, but that are out there in the wild. Having this visibility to them in a central place WILL help interoperability. [I have a feeling this is where we’re going to end up on the un/pw claims]

I think these claims are qualitatively different from the other ones we have discussed.

## True, but they are just claims. And we’re not supposed to be police. We’re not supposed to be passing judgement here.

I will be hard pressed to vote in favor of this.

## Yeah and nobody else has either.

However I want to hear other peoples opinions before I make a final decision on this.

## Me too.

John B.

On 7-Apr-09, at 8:25 PM, Paul Trevithick wrote:

[John Bradley]

OK some questions

Are these claims for a managed card?

Is the STS required to audience restrict what parties it will return these claims to.

That is return the claim values only to a RP that the STS is configured to know may receive the values.

Infocard adheres to the principle that the user choses what information is sent to the RP.  They have the ability to review the identity of the requester and get a display token showing what is being returned.

If the identity of the requester is being hidden in a claim request,  and the user is prompted for a generic card that can return multiple values for these claims, are we properly giving the user the information they need?

If where this is going is password manager functionality built in to the selector, and these claims are for that purpose then I would feel better if we identified them as such.

Perhaps there should be a class of claims that are for the selectors use only.  

As an example:

http://schemas.informationcard.net/@ics/selector/password/2009-03

Then a selector could tell that claim requests coming in from third parties for those claims need to be inspected in some way.

I think username and password are too generic for the intended use.  

I really don't want to give people the idea that it is OK to put usernames and passwords in regular m-cards.

So I prefer to qualify the claim URI in some way with passwordcard or selector or internal.   If they involve special selector logic to use in the intended way.

John Bradley

[Paul Trevithick]

## inline

On 4/11/09 5:34 PM, "John Bradley" <ve7...@ve7jtb.com> wrote:

OK some questions

Are these claims for a managed card?

## The proposal [1] doesn’t say, because they can be used for either personal or managed cards (in different ways)

Is the STS required to audience restrict what parties it will return these claims to.
That is return the claim values only to a RP that the STS is configured to know may receive the values.

## Yes, see the “Notes” section here [1]

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

Infocard adheres to the principle that the user choses what information is sent to the RP.  They have the ability to review the identity of the requester and get a display token showing what is being returned.

If the identity of the requester is being hidden in a claim request,  and the user is prompted for a generic card that can return multiple values for these claims, are we properly giving the user the information they need?

## Well, that’s a fair question. I’ve been thinking for a few weeks now about another selector enhancement wherein an additional “on behalf of” parameter can be passed along with the request from the RP to the selector for the token. This “OBO” parameter would be displayed in the UI of the selector to give the use a sense of where their claim data was going to be forwarded to by the RP.

If where this is going is password manager functionality built in to the selector, and these claims are for that purpose then I would feel better if we identified them as such.

## I (and Higgins) have been focused on a password manager browser extension [2]  talking to an enhanced selector. However Ian Hummel at Azigo and Uppili and others have mentioned of use cases for these same claims being used in RP’s that are web services acting as proxies, and they have run into use cases where these same claims are needed.

## [2] http://wiki.eclipse.org/Password_Cards

Perhaps there should be a class of claims that are for the selectors use only.  

## Well, by “selectors” I unpack this to mean what I wrote above (see [2])

As an example:
http://schemas.informationcard.net/@ics/selector/password/2009-03

Then a selector could tell that claim requests coming in from third parties for those claims need to be inspected in some way.

I think username and password are too generic for the intended use.  

I really don't want to give people the idea that it is OK to put usernames and passwords in regular m-cards.

So I prefer to qualify the claim URI in some way with passwordcard or selector or internal.   If they involve special selector logic to use in the intended way.

## The special antiphishing logic mentioned in note#1 in [1] is: selector’s self-issued STS will have a whitelist that is exactly one entry in length (a short list indeed); the user will explicitly permission some special RP (e.g. the browser password manager) as this one and only whitelisted RP; and the selector will only release un/pw claim values to this RP.

## I don’t understand what additional protection adding the “/selector” string in the claim URI adds. A malicious RP can always add that substring too. I must be missing something in what you’re saying.

[John Bradley]

You are relying on special logic in the selector for processing this safely.

I am concerned what happens when the card is moved to a different selector.

If there was a range of claims that selectors could know should never come from an RP directly, that would allow other selectors to block them.

This would be better than having users move cards to selectors without the special logic.

I think the conclusion with Ian was that using a generic claim like that when you have a remote RP is a bad idea.

If the RP is issuing the m-card then they can and should use a private claim, they are going to ask for a card from there issuer. 

The only thing a generic claim would do is have the card come up in situations where you don't want it to.

Ian do you have a use case for unerversual username and password claims that overlap with the password manager card?

These are claims that require a selector extension.  

I don't think it is unreasonable to create extensions namespaces so that selectors that don't support the extension can block them.

John Bradley

[Mike Jones]

I vote +1.

 

Per the discussion, I’m satisfied with the note about requiring use in a phishing-resistant manner.  Also, per the discussion, I can easily imagine lots of different parties using these claims, so I don’t see them as being vendor specific.

 

I’d rather we approve claims that we may not use than become the “claims police” and thus drive the claims definitions elsewhere and into non-interoperable namespaces.

 

                                                                -- Mike

[Paul Trevithick]

Per [1] here are the results of the voting:

Two members approved (+1)
No members disapproved (-1)

Per [1] this means that this claim request has failed (we need three +1s and no –1s).

--Paul

[1] http://wiki.informationcard.net/index.php/Adding_to_the_Claim_Catalog#CLAIM-VOTE-RESULT_email

[Ian Hummel]

Hi everyone,

Sorry I haven't been keeping up to date on this, but I also would like to vote +1.

- Ian.

[Denise Tayloe]

+1

[Drummond Reed]

If the vote is still continuing, +1.

 

=Drummond

 

---

[Paul Trevithick]

Per [1] here are the results of the voting:

Six members approved (+1) see [2]
No members disapproved (-1)

Per [1] this means that this claim request has been approved (we need three +1s and no –1s).

--Paul

[1] http://wiki.informationcard.net/index.php/Adding_to_the_Claim_Catalog#CLAIM-VOTE-RESULT_email
[2] http://groups.google.com/group/icf-wg-schemas/browse_frm/thread/485297804f507a0e?hl=en%08fb8c36453f731a1#

------ End of Forwarded Message

[Paul Trevithick]

[Paul Trevithick]

Several days ago I summarized the (failed) results of the voting on un/pw claims (see [4]). But since then a number of folks have chimed in an said that they didn’t realize that the voting period was over and/or hadn’t remembered to vote, etc.

Let’s wind back the clock. Let’s start the voting process over again (starting NOW). I have reinstated these as new requests here [5] and I have copy/pasted my original CLAIM VOTE email body text here.

Per our process [1], this email is to call for a vote on the proposed
username and password claims here [2].

On this list and on our calls we have had discussions related to these pair
of claims. Topics have included:

* How these claims could be requested by Information Card compatible proxy

servers or by form filling “password manager” browser extensions acting as
an RP (from the selector¹s POV)

* How they should be used such that the values returned by selectors are

site/app-dependent and further that the password values are different for
each site or app to encourage the highest security. In some use cases this
requires the RP passing a URL of the un/pw login form to the selector as a
parameter, and there is no general agreement on the best way to do this.

* How selectors and password manager plugins need to exercise special care

to prevent phishing attacks. It isn¹t entirely clear how best to do this as
it usually involves authentication of the password manager to the selector
and the mechanisms for doing this (e.g. The browser plugin having its own
cert, etc.) are not yet clear.

Despite the controversy swirling around the outside, there remains the need
for username and password claims. In recognition of the surrounding
uncertainty, I propose that these two be voted as “provisional”--thus
allowing us to update the descriptive text based on what we learn as we
implement systems that use them. The Higgins project, for example, has a
Password Cards [3] project that needs these claims at the least.

My vote is +1. (We are voting here for username and password
simultaneously).

--Paul

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

[2] https://informationcard.net/wiki/index.php/Claim_Catalog
[3] http://wiki.eclipse.org/Password_Cards

-------

[4] http://groups.google.com/group/icf-wg-schemas/msg/58fa6674d544e037
[5] https://wiki.informationcard.net/index.php/Claim_Catalog

[Ian Hummel]

+1 

[Mike Jones]

+1 (again)

 

From: icf-wg-...@googlegroups.com [mailto:icf-wg-...@googlegroups.com] On Behalf Of Ian Hummel

Sent: Monday, May 18, 2009 5:53 AM
To: icf-wg-...@googlegroups.com

[Uppili Srinivasan]

My vote is +1.

----- Original Message -----

[Drummond Reed]

+1.

 

=Drummond

 

---

From: icf-wg-...@googlegroups.com [mailto:icf-wg-...@googlegroups.com] On Behalf Of Paul Trevithick
Sent: Sunday, May 17, 2009 12:25 PM
To: ICF.WG.Schemas
Subject: [ICF.WG.Schemas] CLAIM VOTE (provisional) username & password

 

Several days ago I summarized the (failed) results of the voting on un/pw claims (see [4]). But since then a number of folks have chimed in an said that they didn’t realize that the voting period was over and/or hadn’t remembered to vote, etc.

[Drummond Reed]

This is a request for the Schemas WG to add the following claims to the Claim Catalog:

 

      http://schemas.informationcard.net/@ics/icam-assurance-level-1/2009-06

      http://schemas.informationcard.net/@ics/icam-assurance-level-2/2009-06

      http://schemas.informationcard.net/@ics/icam-assurance-level-3/2009-06

 

Details have been added to the Proposed Claims table at:

 

            http://wiki.informationcard.net/index.php/Claim_Catalog

 

The purpose is to enable RPs to request security tokens issued according to the requirements of the U.S. federal Identity Credential and Access Management (ICAM) Assurance Levels 1, 2, and 3 by an identity provider certified to do so. Note that the claim itself does not verify that identity provider is certified; verification is a separate step that is out of scope. (One option is for the value of the claim to be a URI that an RP can check for signed metadata verifying that the IdP is certified by a trust framework the RP trusts. Another is for the claim value to be a signed object. There are other options as well, which is why verification is out of our scope.)

 

=Drummond

[Drummond Reed]

Schemas WG Members:

 

In adding the proposed ICAM assurance level claims, I noted that the last approved claim:

 

            http://schemas.informationcard.net/@ics/resource-udi/2009-3

 

…does not in fact conform to the ABNF we require – posted at:

 

            http://wiki.informationcard.net/index.php/Claim_URI_Syntax

 

The problem is the date. The ABNF requires two-digit months. So the above claim URI SHOULD be:

 

            http://schemas.informationcard.net/@ics/resource-udi/2009-03

 

We either need to amend our ABNF, or revise the resource-udi claim.

 

Our date format is modelled on the one used by OASIS for its specification dating, and it keeps all dates in a fixed YYYY-MM format. So I would prefer that we just amend the one claim above to conform to the ABNF, and not make that mistake again in the future.

 

(Note that the username and password proposed claims also have this error, but they have not yet been approved, so they can be fixed. Right now it appears that only resource-udi has this issue. The rest of our claim work was done in late 2008 in months that had two digits, so this was not an issue.)

 

To make this simple: are there any objections to just revising the resource-udi claim to conform to the ABNF? If no objections are filed in the next week, I will revise it.

 

=Drummond

 

 

---

From: icf-wg-...@googlegroups.com [mailto:icf-wg-...@googlegroups.com] On Behalf Of Drummond Reed

Sent: Thursday, May 21, 2009 7:21 PM
To: icf-wg-...@googlegroups.com

[Markus Sabadello]

Yes we should just fix it.. I know of only one instance where this claim is already in use, and it will be easy to change there.

Markus

[Paul Trevithick]

Markus,

I agree we should just fix it. But while we’re at it, we could also rename it from “udi” to “udr” (identifier -> reference) based on our discussions (especially with John Bradley) about allowing the an XRD document to be the value of the resource-udr claim instead of requiring that the value be a dereference-able identifier as it is specified today.

Your thoughts?

--Paul

On 6/12/09 5:55 AM, "Markus Sabadello" <markus.s...@gmail.com> wrote:

Yes we should just fix it.. I know of only one instance where this claim is already in use, and it will be easy to change there.

Markus

On Fri, Jun 12, 2009 at 4:09 AM, Drummond Reed <drummo...@cordance.net> wrote:

Schemas WG Members:

?

In adding the proposed ICAM assurance level claims, I noted that the last approved claim:

?

???????????  <http://groups.google.com/group/icf-wg-schemas/msg/4f0d1350087b4949> http://schemas.informationcard.net/@ics/resource-udi/2009-3

?

…does not in fact conform to the ABNF we require – posted at:

?

??????????? http://wiki.informationcard.net/index.php/Claim_URI_Syntax

?

The problem is the date. The ABNF requires two-digit months. So the above claim URI SHOULD be:

?

???????????  <http://groups.google.com/group/icf-wg-schemas/msg/4f0d1350087b4949> http://schemas.informationcard.net/@ics/resource-udi/2009-03

?

We either need to amend our ABNF, or revise the resource-udi claim.

?

Our date format is modelled on the one used by OASIS for its specification dating, and it keeps all dates in a fixed YYYY-MM format. So I would prefer that we just amend the one claim above to conform to the ABNF, and not make that mistake again in the future.

?

(Note that the username and password proposed claims also have this error, but they have not yet been approved, so they can be fixed. Right now it appears that only resource-udi has this issue. The rest of our claim work was done in late 2008 in months that had two digits, so this was not an issue.)

?

To make this simple: are there any objections to just revising the resource-udi claim to conform to the ABNF? If no objections are filed in the next week, I will revise it.

?

=Drummond

?

?

---

From: icf-wg-...@googlegroups.com [mailto:icf-wg-...@googlegroups.com] On Behalf Of Drummond Reed
Sent: Thursday, May 21, 2009 7:21 PM
To: icf-wg-...@googlegroups.com
Subject: [ICF.WG.Schemas] Re: CLAIM VOTE (provisional) username & password

?

+1.

?

=Drummond

?

---

From: icf-wg-...@googlegroups.com [mailto:icf-wg-...@googlegroups.com] On Behalf Of Paul Trevithick
Sent: Sunday, May 17, 2009 12:25 PM
To: ICF.WG.Schemas
Subject: [ICF.WG.Schemas] CLAIM VOTE (provisional) username & password

?

[John Bradley]

At least I got the date part of the GSA claims correct:)


Yes they should all be amended to be two digit months.

John B.

> From: icf-wg-...@googlegroups.com [mailto:icf-wg-...@googlegroups.com
> ] On Behalf Of Drummond Reed
> Sent: Thursday, May 21, 2009 7:21 PM
> To: icf-wg-...@googlegroups.com
> Subject: [ICF.WG.Schemas] Re: CLAIM VOTE (provisional) username &
> password
>
>
> +1.
>
>
> =Drummond
>
>

[Paul Trevithick]

Agree that we should add these.
I’ll vote +1 when you call for a vote.
--Paul

[Mike Jones]

+1

[Mike Jones]

Yes, please fix.

 

                                                                -- Mike

[John Bradley]

+1

while we are at it.

John B.

[Ian Hummel]

+1

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

[Markus Sabadello]

Yes, fine with me.

Markus

2009/6/12 Paul Trevithick <ptrev...@gmail.com>

[Drummond Reed]

Paul, I’m fine with just fixing it, i.e, changing udi --> udr and 2009-3 --> 2009-03, but with two changes, I’m wondering if for our own process integrity we need to revote.

 

Your call as chair.

 

=Drummond

 

---

From: icf-wg-...@googlegroups.com [mailto:icf-wg-...@googlegroups.com] On Behalf Of Markus Sabadello
Sent: Friday, June 12, 2009 11:48 AM
To: Paul Trevithick
Cc: ICF.WG.Schemas; John Bradley; Drummond Reed
Subject: [ICF.WG.Schemas] Re: ISSUE: Claims ABNF not followed

 

Yes, fine with me.

Markus

[Drummond Reed]

Okay, because there appears to be consensus, I’m calling for a vote on the claims below.

 

I vote +1.

 

Paul, note that several others (Mike, John, Ian, and yourself) have “pre-voted” +1.

 

=Drummond

 

---

From: icf-wg-...@googlegroups.com [mailto:icf-wg-...@googlegroups.com] On Behalf Of Paul Trevithick
Sent: Friday, June 12, 2009 7:37 AM
To: ICF.WG.Schemas
Cc: Tebo, Matt (10421); McBride, Terry (10421)
Subject: [ICF.WG.Schemas] Re: CLAIM REQUEST - icam-assurance-levels

 

Agree that we should add these.

[Axel.N...@telekom.de]

+1

---

Von: icf-wg-...@googlegroups.com [mailto:icf-wg-...@googlegroups.com] Im Auftrag von Drummond Reed
Gesendet: Samstag, 13. Juni 2009 08:18
An: icf-wg-...@googlegroups.com
Cc: 'Tebo, Matt (10421)'; 'McBride, Terry (10421)'
Betreff: [ICF.WG.Schemas] CLAIM VOTE - icam-assurance-levels

[Axel.N...@telekom.de]

I hope that we don't have to vote on this syntacticle change. Anyways:

+1 for removing the old claim and +1 to add the new one.

 

Oops. We don't have a "removing from the claims catalog" process, or have we?

Just joking.

 

Please make the change.

 

-Axel

---

Von: icf-wg-...@googlegroups.com [mailto:icf-wg-...@googlegroups.com] Im Auftrag von Drummond Reed

Gesendet: Samstag, 13. Juni 2009 08:15
An: icf-wg-...@googlegroups.com; 'Paul Trevithick'
Cc: 'John Bradley'; 'Drummond Reed'
Betreff: [ICF.WG.Schemas] Re: ISSUE: Claims ABNF not followed

[John Bradley]

+1

[Charles Andres]

I suggest you formally extend the ICF Claims naming specification we began last year (for values such as boolean)  to labels that embed uniform data types (like dates).  That way, a new claim can be accepted, without having to match exactly during the vote.  Such 'typo's can be noted as they are entered into the official schema catalog independent of the vote.

As long as the claim schema catalog is consistent and accurate, developers can use it to write relying party or IdP code to create or parse the claims correctly.

[Paul Trevithick]

+1

[Paul Trevithick]

Hi Charles,
I’m not following you here. I don’t recall the “Claims naming specification.”
--Paul

On 6/13/09 5:49 PM, "Charles Andres" <andres....@gmail.com> wrote:

[Drummond Reed]

I think Charles was referring to the Claims URI Syntax spec:

 

            http://wiki.informationcard.net/index.php/Claim_URI_Syntax

 

It already has all portions of the claim syntax structure specified, so we just need to audit the claims that are submitted against this spec from now on.

 

=Drummond

 

---

From: icf-wg-...@googlegroups.com [mailto:icf-wg-...@googlegroups.com] On Behalf Of Paul Trevithick
Sent: Monday, June 15, 2009 8:13 AM
To: Charles Andres
Cc: ICF.WG.Schemas
Subject: [ICF.WG.Schemas] Re: ISSUE: Claims ABNF not followed

 

Hi Charles,

[Drummond Reed]

So, Paul, as chair, is the decision here to “just fix it” (udi --> udr and 2009-3 --> 2009-03), in which case I’ll “just do it”, or do we need a revote?

 

=Drummond

 

---

From: Paul Trevithick [mailto:ptrev...@gmail.com]

Sent: Friday, June 12, 2009 5:42 AM
To: Markus Sabadello

Cc: ICF.WG.Schemas; John Bradley; Drummond Reed

[Paul Trevithick]

In general I think we should take votes. But in this case (a) we think we know all of the implementations of this claim (b) the changes are purely syntactic and (c) this claim is “provisional”. So risk seems acceptable. Let’s make an exception and “just fix it.” Just this once :) --Paul

[Paul Trevithick]

Got it. Thanks Drummond.

[Charles Andres]

Exactly.

Thanks, Drummond!

Sent from my iPhone

[Drummond Reed]

“Just fixed.” See https://wiki.informationcard.net/index.php/Claim_Catalog#2009.

 

BTW, the status of this claim URI is still provisional, so IMHO that makes it even more acceptable to make necessary revisions such as this.