- Case Number: a20110319.1
- Status: dismissed
- Claimants: Peter F
- Respondents: CAcert
Case Manager: MartinGummi
Arbitrator: UlrichSchroeter
- Date of arbitration start: 2011-03-20
- Date of ruling: 2013-09-16
- Case closed: 2013-09-16
- Complaint: Name Change After Marriage (no chance for w/ Assurance)
- Relief: TBD
Before: Arbitrator UlrichSchroeter (A), Respondent: CAcert (R), Claimant: Peter F (C), Case: a20110319.1
History Log
- 2011-03-15 (issue.c.o) case [s20110315.12]
- 2011-03-19 (Support) case [s20110315.12] moved to disputes
- 2011-03-20 (A): added to wiki, request for CM / A
- 2011-03-20 (CM): I'll take care about this case as (CM)
- 2011-03-20 (A): I'll take care about this case as (A)
- 2011-03-20 (A): sent initmailing with CCA/DRP acceptance request to (C)
- 2011-03-20 (C): accepts CCA/DRP
- 2011-03-20 (A): Request to (Support) regarding (C)'s account infos: Full name, Assurances Rcvd, Assurances Given
- 2011-03-20 (A): questions set #1 to (C) for discovery
- 2011-03-20 (Support): [s20110320.39] response to infos about (C)'s account
- 2011-03-20 (C): response to questions set #1
- 2011-04-04 (A): contacting an Assurer from Fosdem about assistance in this case
- 2011-04-18 (Support): request to prospective OA for Sweden to assist in this case
- 2011-04-21 (pOA-SE): Prospective OA for Sweden accepts to assist in this case
- 2011-04-22 (A): sending questions to prospective (OA-SE) regarding registries SE
- 2011-04-22 (A): progress report to (C)
- 2011-04-26 (pOA-SE): answered questions
- 2011-04-27 (A): request #2 to (pOA-SE)
- 2011-05-07 (pOA-SE): proposal with photo copy of two (2) different old and new identity cards / passport, together with a recent tax authority person statement ("personbevis")
- 2011-06-21 (C): progress report request
- 2011-06-22 (A): response to (C), current state
- 2011-06-22 (C): other CA accepted a photocopy/scan of the government notification that they changed the people-registry (folkbokföringen).
- 2011-06-22 (A): CAcert is not other CA's - explanation of the secure chain path procedure(s)
- 2011-06-23 (C): proposal about a "Personnummer" procedure
- 2011-06-26 (pOA-SE): response about "Personnummer" proposal
- 2011-06-27 (A): some thoughts relating to Pwd-reset procedure to (C), (pOA-SE)
- 2011-06-27 (C): comments to proposal dated 2011-06-27 by (A)
- 2011-06-29 (C): 2nd comment to proposal dated 2011-06-27 by (A)
- 2011-06-29 (C): answer from old email account regarding to proposal dated 2011-06-27 by (A)
- 2011-06-30 (pOA-SE): comments to proposal dated 2011-06-27 by (A) and comment by (C) dated 2011-06-29
- 2011-07-01 (A): proposal for a identity verification procedure thru "CAcert approved registry" for name change after marriage verifications to (pOA-SE), (C), (CM)
- 2011-07-01 (A): sending proposed workflow as chart name-change-w-registry-se-proc1.png to (pOA-SE), (C), (CM)
- 2011-07-11 (C): I seriously like the idea of using tokens, with some modification suggestions
- 2011-07-18 (C): suggestion with 3 tokens
- 2011-07-18 (A): awaiting response from (pOA-SE), sending info to (pOA-SE), (C), (CM)
- 2011-07-23 (pOA-SE): I will look into this once I'm back in about one week.
- 2011-09-11 (C): I would like to have my cacert account deleted.
2011-09-11 (A): there is no other way as to go thru arbitration FAQ: How To Terminate
- 2011-12-16 (iCM of case a20111004.1): transfered to disputes queue
Original Dispute, Discovery (Private Part)
Link to Arbitration case a20110319.1 (Private Part)
EOT Private Part
Discovery
- 2011-07-01 (A): sending proposed workflow as chart name-change-w-registry-se-proc1.png to (pOA-SE), (C), (CM)
- 2011-07-18 (C): suggestion with 3 tokens
I'm sorry but I still can't quite follow the procedure. However I understand that you plan to send Token A to both requester and third party and I think that may perhaps be a mistake. My suggestion is to generate three tokens: Token A - Could preferably be some "case number" which follows all mails regarding the case. (If for some unlikely reason the requester needs to communicate to third party.) Token B - is for communication between arbitrator and Requester. Token C - is for communication between arbitrator and third party (-ies). Requester should not know about third parties.Requester must not know Token C. The third party should only validate information that comes from the arbitrator. If the requester and the third party can communciate he can either put pressure on the party to make a false validation, or supply a different set of information than he did to the arbitrator. I.e - the requester should supply any and all info to the arbitrator. The arbitrator contacts one or two third parties who validates the info and responds back with the correct tokens and their result.
Ruling
- Case late dismissed.
The case made some progress in the starting phase, but runs into a deadlock where no reliance chain path could be established according to yet known CAcert verification procedures (a20110330.1 Name Change after Marriage w/ Assurance - Precedents Case).
- A deployment of another reliance chain path gots stuck.
1.5 months after last activities (2011-07-23) on "Name Change w/ Registry SE procedure" a new dispute has been filed by (C) a20111004.1 Assurer requests deletion of his account (2011-09-11)
Execution
- 2013-09-16 (A): documentation updated, case late dismissed.
2013-09-16 (A): notifications to (C), (CM), (CM of case a20111004.1), (A of case a20111004.1) (a20111004.1), case closed.
- 2013-09-16 (A): NDR received for 2nd email addr of (C), NDR forwarded to (CM of case a20111004.1), (A of case a20111004.1)
Similiar Cases
See also: Arbitration Training - Lesson 23 - Support case: Name Change due to Marriage